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jylOBIDIC and Fieldata 
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In the 1950s, the “ Golden Age of the Signal Corps,” a farsighted U.S 
Army Signal Corps program foreshadowed many of the advanced 
computing and communications technologies that were not to be generally 
available for several decades. These technologies included compatible 
computers made by several manufacturers, high-availability systems, 
standardized interfaces and communication codes, and large-capacity disk 
files. The early genesis of Fieldata is described as well as the development 
program for the mobidic machines. Details on machine reliability are 
provided, together with descriptions of the Fieldata code, the mobidic 
instruction set, the operation of the mobidic I/O converters, and the 
mobidic real-time system. 

Categories and Subject Descriptors: K.2 [Computing Milieux]: History 
of Computing— hardware, software, systems. C. 1 . 1 . [Computer Systems 
Organization]: Processor Architectures— single data stream architectures 
B.O. [Hardware]: General. 

General Terms: Design, Management, Standardization 
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the end of World War D, the promise of 
computing was recognized by many peo- 
4 work at such U.S. academic centers as 
he i'wrwsity of Pennsylvania, Princeton, Har- 
nd MIT had excited a great deal of inter- 
Wfc Mich of this early exploratory work was di- 
Mpported by the military, and some of then- 
planners realized that this new tech- 
ttold well revolutionize the entire mi li- 
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US. Army Signal Corps played a key role 
this technology; Harold (Hal) Silver- 
^ _ *1 assistant to the chief signal officer 
at the time, rec alls that "the whole 
f^sfram was charged up, exciting, and 
extraordinary results in a short time . . „ 
* happy band of warriors, trusting in 


p while the author was employed 
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, Software Engineering Institute, Car- 
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each other ... a verbal request or a handshake 
was a binding commitment.” 1 

From this early ferment and excitement, the 
Signal Corps spawned the Fieldata program and 
the mobidic (MOBUe Digital Computer) family of 
computers. Fieldata was a comprehensive com- 
puter-communications program that envisioned 
the coupling of on-line computers and communi- 
cations systems in worldwide networks. Though 
the operational feasibility of such systems did not 
become practical for several decades, the early ex- 
periences of this program had far-reaching con- 
sequences. mobidic, for example, was "the first, 
fully transistorized, large-scale, general-purpose 
computer to be delivered by a manufacturer to a 
customer” (Lipton et al. 1964). 

The Signal Corps’ Fieldata program was based 
on a different thesis than the early Ordnance 
computer efforts with the eniac and edvac. In the 
army of the mid-1950s, there were several differ- 


Harold Silverstein made these comments in a set of notes 
he prepared for me in October 1985 as background for this 
paper. 
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ent points of view on the role of the computer in 
the military. The Ordnance Corps had sponsored 
eniac’s development to assist in computing bal- 
listic tables, and they saw the role of computers 
as mathematical computation engines or special- 
purpose controllers in weapons. Ordnance work 
centered around the Ballistic Research Labora- 
tories at Aberdeen Proving Ground with the eniac 
and edvac. Several small special-purpose com- 
puters were also developed by Ordnance for sup- 
port of artillery and air defense. One of the most 
successful was fadac, the Frankfort Arsenal Dig- 
ital Automatic Computer, later renamed the Field 
Artillery DAta Computer. 

The Adjutant General’s branch of the army 
thought of computers as accounting machines to 
be used as simple extensions of the punched-card 
accounting systems then in use. Thus they con- 
centrated on applying commercially available 
equipment to the mechanization of personnel, ac- 
counting, and administrative tasks. 2 

The Signal Corps had a radically different view 
of computers. From his role as chief signal officer 
of the U.S. Army Signal Corps, J. G. O’Connell 
knew that the first operational electronic com- 
puter had been the British Colossus. This was a 
classified cryptographic machine that had been 
used for analysis of communications intercepts well 
before the eniac was put to work on ballistic com- 
putations. The communications industry in the 
U.S., however, continued to concentrate on elec- 
tromechanical technology, so the first American 
computers were developed by the electrical en- 
gineering departments of the leading universi- 
ties. 

In 1954, Harold Silverstein advised O’Connell 
of the enormous potential of electronic data pro- 
cessing in meeting the army’s tactical and sup- 
port requirements. 3 He saw that this new tech- 
nology was a logical extension of the Signal Corps 
existing communications mission and recom- 
mended that the army’s missions, staffing, and 
development organizations be restructured. First, 
his proposal for a tactical proving ground to sup- 
port the Signal Corps’ combat role resulted in the 


^Bill Luebbert kindly prepared extensive notes for this pa- 
per on .the early role of the military in computer development. 
Much of the background material in this paper was taken from 
this source. 

3 Harold Silverstein was most helpful in reviewing and 
commenting on this paper and providing much of the infor- 
mation on early Signal Corps work with computers and the 
Fieldata program. 
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army’s opening of the Fort Huachuca proving 
ground in Arizona. Second, he proposed that the 
Signal Corps go "all out” in both the tactical and 
nontactical areas of electronic data processing 
(EDP). Since the 1950 U.S. Census, Silverstein had 
become increasingly convinced of the potential of 
computers and had carefully followed the Phila- 
delphia Signal Supply Agency’s 1952 studies to 
replace their eam equipment with commercial 
machines. After talking with the R&D engineers 
at Fort Monmouth in 1953, he became convinced 
of the bright future for military computers in 
supporting the army’s combat role, so he started 
to prepare a comprehensive proposal for the chief 
signal officer on this subject. 

From the very beginning, the Signal Corps had 
insisted that integrated computer/communica- 
tion networks were the wave of the future and 
that the development of these two technologies 
should be coupled. They supported this highly 

B 



^utroversiEil position by pointing out that these 
two fields were technically very closely related 
jjjjce they derived from common science and tech- 
gology. Many of the officers in both the Sig nal 
Corps and Ordnance disagreed, however, and the 
Opiate was not resolved until the deputy chief of 
I# aiT in Logistics organized a task force in early 
that included all the technical services. They 
were charged with assigning army-wide respon- 
Itbilities for electronic computers. Their conclu- 
sion was the army would best be served if 
the chief signal officer were given the staff, lo- 
isstical, and operational responsibilities for elec- 
tronic data processing. The Signal Corps thus got 
ibe functions of research and development, pro- 
curement, supply, career development, opera- 
ttons, and training for general-purpose computers 
tad associated peripheral equipment. The chief of 
ardnance was given the responsibility for those 
special-purpose computers that were an integral 
part of weapons systems. 

As a result of this, the chief signal officer also 
gained responsibility for planning, authorization, 
and control over the acquisition of all of the ar- 
my'* nontactical or business computers. These 
principally commercial devices were thus to be 
handled according to the regulations and proce- 
dures used for the acquisition of signal commu- 
nications systems and equipment. To carry out 
these responsibilities, the chief signal officer took 
immediate steps to inform the army on EDP by 
educating and training Signal Corps and other 
branch officers and men on applications, employ- 
ment, operation, and maintenance and initiating 
a major research and development, testing, and 
•valuation program. 

In 1955, the chief signal officer requested the 
commanding general of the Continental Army 
Command to sponsor and jointly undertake de- 
velopment of military requirements, concepts of 
equipment, and applications development for EDP 
fer combat and combat-support functions for the 
f-tid army. This ultimately led to the Fieldata 
program and the development of a family of mil- 
itary computing and communications machines. 
••381DIC, a MOBIle Digital Computer for U.S. 
Army field use, was the first of these develop^ 
sent contracts in a program that ultimately grew 
l> include a compatible family of computers, new 
* St * communication systems and devices, soft- 
? nd systems standards for both hardware 
software. 

The Fieldata program quickly became the cen- 
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terpiece of the Signal Corps’ initiatives in EDP 
and the Signal Research and Development Lab- 
oratory and Signal School at Fort Monmouth, the 
Army Electronic Proving Ground at Fort Hu- 
achuea, and the Signal Career Development Staffs 
undertook an aggressive and coordinated effort. 
The Signal R&D Laboratory was given the de- 
velopment role for the computing and communi- 
cations systems while the" Electronics Proving 
Ground in Fort Huachuca was assigned respon- 
sibility for organization and procedures as well as 
systems and equipment testing to assure ade- 
quacy of the resulting systems for field army use. 

The other combat and support branches of the 
army, together with their respective combat de- 
velopment centers, were also involved with such 
projects as the combat intelligence Tactical Op- 
erations Center, the Integrated Army Air De- 
fense System (iaads), and the Army Area Com- 
munications System. Project mass applied data 
processing to the logistics problems of the Sev- 
enth Army in Europe, and the U.S. Army Intel- 
ligence Board conducted studies on the use of data 
processing in tactical intelligence. Overall, the 
Continental Army Command (conarc) initiated 
nearly 100 studies on the application of data pro- 
cessing in the field army and assigned them to 
such groups as the Command and General Staff 
College, the Army Intelligence Board, the Artil- 
lery and Guided Missile School, and the Army 
Electronics Proving Ground (Luebbert undated; 
USASRDL undated). 

Two general officer’s seminars were run by the 
chief signal officer, one at the U.S. Military Acad- 
emy at West Point and the other at the Signal 
School at Fort Monmouth. These gave over 40 
general and flag officers a grounding orientation 
in data processing through special "hands-on” 
courses. Special Signal Corps teams also gave ed- 
ucational programs at the Industrial College of 
the Armed Forces, the U.S. Army War College, 
the Command and General Staff College, and other 
military schools. 

While many divisions of the army focused on 
developing the operational know-how to apply this 
rapidly developing technology, the Fieldata 
equipment program at Fort Monmouth was also 
beginning to take shape. Ultimately, a family of 
compatible computers was planned which could 
be interconnected through data communications 
links so that messages, data, and programs could 
be electronically interchanged. This ambitious and 
farsighted program called for the development of 
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data communications standards and codes, com 
patible computers with common instruction set , 
and a family of consistent interfaces, procedures, 

ail lJtiafwk on the Fieldata program started a 
few years after the conclusion of the Korean war. 
Had the program not been prematurely trun - 
ated in the early 1960s, it would likely haveae- 
celerated the marriage of computers and com- 
munications which industry accomplished over the 
next 25 years. In the technology of the time, these 
developments were extremely challenging, but the 
rapid progress of the Fieldata program between 
1955 and 1962 was largely due to the active an 
informed leadership of the chief signal officer and 
a cadre of unusually talented young officers and 
staff. Before its promise could be fully realiz , 
however, the program came to an untimely en . 
This was caused by the 1962 reorganization of the 
army which destroyed the central focus for the 
Fieldata program. The appropriations that sup- 
ported this work came largely from R&D and pema 
Ends (Production of Equipment and Material 
Army) which the chief signal officer had author- 
ity to dispense. The elimination of the technical 
services in 1962 meant that no central funding 
authority was thenceforth available. This h p 
pened just as early army funding demands were 
being felt in anticipation of the Vietnam conf } lc ’ 
and this resulted in such radical changes in bud- 
get priorities that the Fieldata program was dis- 

C °The U final impact of Fieldata will never be 
known but it clearly pioneered many key areas o 
data processing and data communications and 
benefited the U.S. Army in its early data pro- 
cessing work. The Fieldata system developed a lrne 
of compatible computers, a high-availability du- 
plexed computer system, real-time computer-com- 
munication facilities, and standard communica- 
tion codes. Many people in industry and the 
military were introduced to data processing 
through the Fieldata program. Unfortunately, few 
of the Fieldata system’s early results have been 
published so this experience has not been avail- 
able in organized form (Crawford 1959; Luebbert 
1959). Many of the people involved, however, have 
carried this knowledge with them and helped to 
pave the way for the practical implementation ot 
the concepts they pioneered. 

The Stanford Captains 

Not everyone in the Signal Corps was willing to 
accept O’ConneH’s view that computers and com- 


munications should be treated as a unified field. 
Many felt that work on computers, radar, and other 
electronic systems was a diversion from their pri- 
mary interest— communications. At the mam 
Signal Corps R&D Laboratory at Fort Monmouth, 
New Jersey, the computer activities were located 
at the satellite Evans Signal Laboratory about 16 
miles away, where radar and other work not con- 
sidered in the mainstream was performed. 

O’Connell, however, gave his special assistant 
Harold Silverstein the task of implementing the 
concepts they shared and Silverstein thus became 
the focal point for the army’s new interest in com- 
puters. He started by requesting the involvement: 
of the Army Communications Systems Division 
(ocsigo), which was the Signal Corps department 
responsible for large electronic commumcation* 
systems. They assigned Benedict Jacobellis as 
project officer to work with Silverstein. His role 
was to plan and manage the connection of com- 
puters with existing and future communication* . 

^tn^arly 1956, while these two were in San 
Francisco to attend the Western Joint Computer 
Conference, they met with four young Signal Corps 
captains at the Stanford University graduate 
school. Their brainstorming session was so suc- 
cessful that Silverstein decided to makearrange- 
ments for Grady Bannister, A1 Crawford, Georg* 
Fullerton, and Bill Luebbert to play important 
roles in the new army data processing program. 
At Silverstein’s suggestion, these four were asked 
to stay an extra year at Stanford and take every 
possible computer course and seminar tbat Stan- 
ford would offer. This meant a second master’s de- 
gree for Bannister, Crawford, and Fullerton and 
a Ph.D. for Luebbert. 

Freaderick Terman, who was then dean of en- 
gineering at Stanford, made a spemal effort to^ 
commodate the Signal Corps’ desire for expanded 
computer and information processing courses and 
arranged for the Stanford faculty and research 
scientists from the Stanford Research Institute to 
create several new courses. Some of the faculty 
members involved were DougEngelbart (who 
vented the mouse), Lou Fine, John Hemott, Geny 
Liebermann, Jerry Noe (who later headed th* 
Computer Department at the Umversi y 
Washington), Bob Oakford, Alan Petersen, and 

Karl Spangenberg. uun he wrt 

When Bill Luebbert completed his PhJ) . 
sent to Fort Monmouth for R&D; Crawford, Ban- 
nister, and Fullerton, each with second masg* 
degrees, went to Fort Huachuca for operational pian 
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iRg. Army Supply in Philadelphia, and Army 
in the Pentagon, respectively. These four of- 
played major roles in advancing EDP in the 

.. fvniflftfl the aercrrpcsive Ant.HneiosrH/* 


f ^hly professional pertormance oi scores of young 
^nal officers who were mounting this techno- 
fyncal revolution in the army. As Silverstein said: 

] 0 t of these young captains made good in every 
and some rose to two- and three-star rank. 
^>re were many who didn’t rise and shine but 
■yiftiy produced heroic results” (Silverstein 1985). 

gill Luebbert’s work, along with young civilian 
engineers at the Signal R&D Lab at Fort Mon- 
gpouth, led to mobidic and the Fieldata program. 

other captains focused on the uses of data 
pyocessing in the army. At Fort Huachuca, for ex- 
ample, Crawford and Hugh Foster worked with 
(ONARC to initiate many operational studies on 
the uses of DP for such tasks as aircraft traffic 
<ontrol, communications management, armor 
planning, artillery fire planning, amphibious 
aovements, and air drops. At the Signal School 
ether young officers set up systems analysis 
courses to teach the officers from the using 
branches how to automate their respective areas. 
A comprehensive set of officer and enlisted MOS 
courses were soon established and the chief sig- 
nal officer directed that all signal officers become 
qualified on EDP as part of their professional ca- 
reer development. This priority focus on the 
training of young signal officers unquestionably 
had greater impact on the operational capability 
ef the army than all the R&D and hardware pro- 
grams combined (Silverstein 1985). 


The Fieldata Program 


Fort Monmouth 

As pressures built for more computer work in the 
Signal Corps, the Fort Monmouth laboratory re- 
alized that their limited efforts at the nearby Ev- 
ans Signal Laboratory were totally inadequate. 
Thus they decided to replace their small Electro- 
iata computer with an International Business 
Machines (IBM) 704-class machine. Unfortu- 
Mtely, normal funding was not available so Lieu- 
tenants Herb Brun and Rolf Kates, who had just 
returned with MIT engineering degrees, were 
given the job of writing the specifications for a 
suitably nigged machine that would qualify for 
available funds. They decided on a 37-bit 
transistorized machine to be mounted in an army 


van. This was the birth of mobidic, the MOBIle 
Digital Computer. 4 

At about this time, Silverstein had completed 
a series of discussions with both the Stanford cap- 
tains and the Signal R&D Laboratory which con- 
cluded that the Fort Monmouth computer and 
communication R&D work should be put under 
the same organization. This was accomplished just 
before Luebbert arrived from Stanford to work in 
this newly combined organization which he was 
to head two years later. By the time Luebbert got 
to Fort Monmouth, the mobidic specifications had 
been nearly completed. Coordination by the R&D, 
procurement, and comptroller staffs in the Office 
of the Chief Signal Officer resulted in agreement 
that the mobidic procurement could use com- 
bined development and production funds (Lueb- 
bert 1985; Silverstein 1985). 

The Fieldata Computers 

One of the first things Luebbert did in his new 
job was to modify the mobidic environmental 
specification so it would be a truly militarized 
machine. In early 1956, bid requests were sent out 
to almost every major electronics firm, including 
IBM, Radio Corporation of America (RCA), Sperry 
Rand, Philco, Burroughs, and Sylvania. Surpris- 
ingly, of the major firms only Sylvania and RCA 
submitted proposals, and Sylvania, which had a 
lower price, was judged to have a techically su- 
perior proposal. As soon as they got a letter of 
intent, Sylvania started work immediately, even 
though a contract wasn’t officially signed for sev- 
eral more months. As Silverstein points out, "I sent 
them a letter of intent and they kept plowing 
ahead, spending money on trust, and calling me 
at least once a week on getting the formal con- 
tract before a lot of good Sylvania execs got fired 
(there were moments when I was scared about the 
funding but kept a bold front)” (Silverstein 1985). 

Shortly after Sylvania received the award in 
October 1956, the other established computer firms 
realized that this could become an important pro- 
gram and started to show increasing interest. Since 
the original $1.6 million mobidic contract ulti- 
mately grew to a total of over $30 million of Syl- 
vania contracts, their reactions were clearly war- 
ranted (Sokol 1967). Relatively soon thereafter, 
two more development contracts were let to IBM 

4 In a private communication, Luebbert explained that Carl 
Doering, who was for a time number two under him at Fort 
Monmouth, originated the name mobidic. 
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MOBIle Digital Computer 


Figure 1 . Artist’s concept of 
mobidic installation. 


and Philco for the Basicpac and Informer, respec- 
tively. These were smaller compatible members 
of the Fieldata family. Another development con- 
tract for a small compatible machine, Logicpac, 
was let to RCA but I have found no record of its 
being completed. 

mobidic set the basic architectural character- 
istics for this entire family. It was a transisto- 
rized parallel machine with a 37-bit word plus 
parity, 4096—28,672 words of 8-microsecond ran- 
dom access core memory, a 1-megacycle clock, and 
52 instruction types. The typical instruction time 
was 16 microseconds, with multiply and divide 
taking 86 and 88 microseconds, respectively. The 
machine had from four to seven index registers, 
could handle 63 I/O devices, and had a real-time 
system with up to 32 externally addressable reg- 
isters. The I/O architecture included converters 
that behaved much like today’s channels, except 
that each converter could address every I/O de- 
vice. Up to four converters were included in the 
mobidic architecture, permitting four simulta- 
neous I/O operations. 

In all, five mobidic computers of two basic de- 
signs were built, all by Sylvania. mobidics a, c, 
D, and 7A all had identical internal structures, 
whereas the compatible mobidic b was both 


smaller and had a different data flow. These ma- 
chines were all designed to fit in a trailer van, as 
shown in Figure l. 5 

As the initial machine, MOBIDIC A (later des- 
ignated the AN/MYK-1) was built to test many 
of the Fieldata concepts and to demonstrate over- 
all program feasibility. It was delivered on sched- 
ule in December 1959 to Fort Monmouth where 
it successfully underwent a wide range of envi- 
ronmental and electronic tests before being used 
for data processing support in the laboratory. 

mobidic b had a duplexed design and a special 
information retrieval facility to support the com- 
mand and control tasks of the Tactical Opera- 
tions Center at army command posts. It was de- 
livered, and successfully performed its function in 
the Army Tactical Operations Center (artoc) tests 
at Fort Leavenworth, Kansas, artoc, however, 
proved not to be feasible in the technology of the 
time because the required total of 15 tractor-trailer 
vans of equipment was more than the army could 
visualize for a mobile field operations headquar- 


5 This figure was supplied by the Communication Elec- 
tronic Museum of the U.S. Army in Fort Monmouth, New Jer- 
sey. ,'JB | 
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It was intended to support such tactical applica- 
tions as field artillery fire control (van de Velde 
1960). Though initially planned for the A-141 
shelter (helicopter hut), it was too large and was 
put in a truck, as shown in Figure 2. It was a 
transistorized serial-parallel machine with mag- 
netic core memory and a 24-microsecond add time. 
Philco, the contractor, was interested in expand- 
ing the machine’s capabilities but the Signal Corps 
was most interested in small physical size and so 
considered various alternate configurations which 
they called Logicpac and Compac. Though these 
machines were never built, they were intended to 
support the lowest tactical army echelons for sur- 
veillance, weapons systems, meteorology, and ar- 
tillery support (Luebbert undated: USASRDL un- 
dated). The only Basicpac computer that was built 
was delivered to Fort Monmouth where it suc- 
cessfully completed its tests in February 1961 
(Datamation 1961). Unfortunately, further acqui- 
sition of the Basicpac computer was stopped and 
this member of the Fieldata family was never de- 
ployed (Silverstein 1985). 

The Informer was intended for use in tactical 
intelligence operations and as the central switch- 
ing control machine in military data communi- 
cations networks. Unfortunately, IBM chose to use 
a new type of magnetic core logic for the circuitry 
and ran into severe problems. After the bulk of 
the contract funds had been expended on circuit 
development and retrieval technology, the Signal 


Figure 2. Artist’s concept of 
Basicpac shelter installation. 
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Corps cancelled the contract and the machine was 
never delivered (Luebbert 1985). The develop- 
ment efforts on the Informer did, however, make 
a significant contribution to future search and re- 
trieval systems (Silverstein 1985). 

Fieldata Communications 

At the start of the Fieldata program, communi- 
cations equipment was almost entirely voice or 
teletype and none of the facilities needed for data 
communications had yet been developed. Lueb- 
bert and his colleagues at Fort Monmouth soon 
realized that standardized data rates and com- 
munication codes were essential. Higher speeds 
than teletype were clearly required but there was 
initially no clear guideline on what speeds should 
be used. 

Since the Signal Corps was then dedicated to 
teletype equipment, the Baudot code (the teletype 
standard) seemed a logical place to start. It used 
five data bits, one start bit, and a stop bit of at 
least 1.42 units. If this total was rounded to 7.5 
bits per character, the standard 100-word-per- 
minute teletype machine would operate at 600 
characters per minute, 10 characters per second, 
or 75 bits per second. Luebbert proposed that this 
be the basic unit of data communications fre- 
quency and that all higher frequencies should be 
multiples of it. Based on his computer training, 
he decided to use powers of 2 which resulted in 
such subsequent common facilities as the 4800- 
and 19,200-baud lines (Luebbert 1985). 

Another military concept that was developed 
in parallel with Fieldata was the basic system of 
army battlefield communication. Previously, each 
division and corps had its own communications 
facilities and every time a headquarters moved, 
it had to establish an entirely new communica- 
tions network (Luebbert 1985). Field communi- 
cations, therefore, were handled over a maze of 
copper wires that were strung between the mobile 
headquarters units and restrung every time the 
units moved. The back lines were thus almost lit- 
erally paved with copper wire. To prove the im- 
practicality of this setup, one enterprising colonel 
developed a tactic during war game maneuvers at 
Fort Bragg, North Carolina in the early 1950s. 
One night he sent a couple of tanks in a fidl-speed 
circle around the enemy headquarters. They were 
instructed to avoid any engagements and to re- 
turn immediately across the lines. This simple ploy 
severed all communications between headquar- 
ters and the field units, thus rendering coordi- 
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nation impossible. In the morning, a sudden and 
devastating attack won the day. Subsequent ma- 
neuvers, particularly tests of the dual-capable 
atomic and nonatomic army, demonstrated the 
need for an area-grid system using radio circuits 
for mobility, flexibility, and survivability (Silver- 
stein 1985). 

An area-grid communication system permitted 
each unit to be connected and disconnected to nodes 
of the grid when they moved. The communica- 
tions facilities were thus not associated with di- 
vision or corps but established by geographical area 
and by the Meld Army Signal organization. It was 
recognized that this would require a highly 
adaptable control and addressing system, and the 
Informer was planned to fill this need (Luebbert 
1985). This approach was established in time for 
the Vietnam War and has been the basis for arrnv 
field communications ever since. 

In parallel with these developments, the Fiel- 
data program also initiated a number of com- 
munications equipment developments, such as: 

AN/TSQ-7 — a digital data transmission unit 
developed by Bell Telephone Laboratories to 
transmit digital data over voice circuits in the 
frequency band from 300 to 2,600 cps. The unit 
was cabinet mounted for tactical or fixed plant 
use, weighed 450 pounds, and consumed 570 watts 
(transmitter) and 490 watts (receiver) (USASRDL 
undated; USASEL undated). 

AN/FGC-54 — a long-distance synchronous data 
transmission unit for 40 simultaneous teletype 
channels over a single voice-grade circuit. It was 
developed by Collins, weighed 1,500 pounds, and 
was designed for fixed plant use (USASRDL un- 
dated). 

AN/TSQ-35 — a unit that transmitted 48 chan- 
nel PCM in the 48-kc band between 12 and 60 kc 
used by military and commercial cable and car- 
rier circuits. 6 No record has been found of the fi- 
nal disposition of this equipment. 

A family of Fieldata code converters was to 
match the new devices to existing equipment, 
which was necessary because the new machines 
used the newly devised Fieldata code. (The Fiel- 
data code is discussed in the Fieldata Standards 
section as well as in Appendix A.) The CV-690 
served as a high-speed buffer and translator be- 
tween magnetic or high-speed paper tape trans- 
ports and communications transmission equip- 


6 This material came from various undated and unpub- 
lished Signal Corps memoranda on the status of several Fiel- 
data projects. 
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njent It was developed by Collins, weighed 70 
Ljunds, consumed 100 watts, and could operate at 
rsther 150 or 300 Fieldata characters per second, 
fbe development contract was let in June 1958 
# jth delivery for August 1959 7 (USASEL un- 
dated). 

The CV-691 Data Concentrator was to bridge 
jj* performance gap between the Fieldata com- 
puters and the then-existing teletype circuits. It 
intended to accept 32 simultaneous 100-word- 
per-minute teletype inputs; provide buffering, er- 
ror checking, and control; convert to the Fieldata 
tude; and interface to the Fieldata TSQ-33 com- 
munications channel. 6 

A small general-purpose converter was also 
planned with plug-in packages to provide high- 
speed (up to 50,000 characters per second) con- 
version between the Fieldata code and such cur- 
rent communications codes as the 4 out of 8 IBM 
transceiver code, Baudot (teletype) code, and the 
IBM 705 code used by the Army Signal Supply 
Agency (the Fieldata code is discussed in the sec- 
tion of this paper entitled "Fieldata Standards”). 
The original contractor was Anderson Nichols, but 
no record has been found of this equipment being 
manufactured or deployed. 7 

A cryptosecunty adapter was also planned to 
encrypt up to 40 simultaneous teletype commu- 
nication channels at rates of up to 75 bps each. 
Again, there is no record that it was ever built 7 
(USASEL undated). 


> 

V 


Fieldata Input-Output Equipment 


A family of computer input-output equipment 
(listed below) was also developed under Signal 
Corps contract for the Fieldata family. It was all 
specified to meet the Fieldata environmental and 
compatibility requirements. 

A contract was let to Ampex for magnetic tape 
transports in June 1958 for the delivery of test 
models in January of 1960. These were 16-chan- 
nel units with 150-inch-per-second transport speed, 
300-bits-per-inch packing density, full parity 
Checking, and 3,600-foot 1 mil mylar 1/2 or 3/4 
inch tape reels. The units were to weigh 500 
pounds, mount in 19 inch relay racks (Figure 3), 
If use 0.76 kva power 7 (USASEL undated)’ 
These devices were developed but they were not 


The source for this information is a series of unpublished 
’HM Corps specification sheets on various Fieldata devices 
/proximate date, 1958, with the notation MON # 3737-1- 


Figure 3. Fieldata magnetic tape transport. 


widely used. The army mobidic installations in 
Europe ended up using commercially available 
tape transports instead (Gazzola 1985; Sokol 1967). 

Anderson Nichols developed a high-speed 
printer under a Signal Corps contract that was 
let in July 1958 with planned delivery for Feb- 
ruary I960. The machine was to print 600 or 900 
lines per minute of 80 to 120 characters per line. 
It was designed for van installation and was to 
operate from +32 to +132° F and be able to with- 
stand storage from -80 to +160° F. It was to pass 
full vibration and shock tests and weigh approx- 
imately 250 pounds. 7 No record has been found of 
the success of this development. 

Anderson Nichols also held contracts for sev- 
eral devices for key entry, paper tape reading and 
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punching, and code converting. These units were 
also contracted for in July 1958 for delivery in 
February I960 and were to be capable of opera- 
tion and storage over the same environmental 
conditions as the page printer. 7 Again, however, 
no record has been found of the outcome of such 
contracts. 

A large-capacity magnetic disk storage unit was 
developed for the mobidic b computer by the 
Bryant Gauge and Spindle Company to provide 
50 million bits of storage capacity. The unit was 
mounted with a horizontal axle and had eight 34- 
2 inch diameter magnetic disks with a total of 4,096 
tracks per surface. The machine was over six feet 
tall and had special provisions for rotating the 
bearings so they would wear evenly. Data were 
stored serial-serial with a clock rate of 150 kc and 
a maximum random access time of 0.25 seconds. 
Although the machine did function, only the two 
initial units were built (Cohler 1985: Lipton et al 
1964). 

Many other devices were planned by the Sig- 
nal Corps for the mobidic family, but these units 
were the major developments, and it is presumed 
that the rest were not completed for lack of fund- 
ing. A partial list of the Fieldata equipment con- 
tracts is given in Table l 7 (USASRDL undated; 
USASEL undated). 


Fieldata Programming 

During this entire period, internal rivalry was 
growing between the communications and com- 
puter people at Fort Monmouth. The communi- 
cations faction was wedded to teletype and felt that 
computers were a temporary fad. They thus at- 
tempted to redirect any computer I/O funding for 
use on teletype equipment. While Luebbert man- 
aged both computer and communications R&D, he 
was able to control this to some degree. He did 
not have an entirely free hand on how the funds 
should be spent, however, or what- programs would 
receive emphasis. Though he felt that more should 
be done both with I/O equipment and program- 
ming, he was unable to get enough funds for either 
more I/O development work or for programming. 
Bill chose to emphasize programming with the 
limited additional funds he was allowed (Lueb- 
bert 1985). 

A number of programming development con- 
tracts were let to Sylvania for basic software which 
included an assembler, some mathematical rou- 
tines, and a set of utility programs. Development 
of a COBOL compiler was started in 1959 (Sammet 
1985; USASRDL undated), but Sylvania did this 
work on its own without army funding. 

The Signal Corps also supported work on the 




Table 1 . Fieldata Equipment Contracts (partial list) 


Contract 

Machine Manufacturer Date 


General Purpose Computers 

MOBIDIC 

Basicpac 

Informer 

Data Communications Equipment 
AN/TCC-30 TTY Terminal 
AN/FGC-54 3000 bps 
AN/TSQ-35 19,200 bps 
Cryptosecurity Adaptor 
Data Concentrator 
Code Converter 
Input-Output Equipment 
Electric Typewriter 
Paper Tape Reader 
Paper Tape Punch 
TTY/Paper Tape Punch 
High Speed Printer 
Paper Tape Transport 
Magnetic Tape Transport 


Sylvania 

10/56 

Philco 


IBM 


Stelma 


Collins 


Bendix 


Collins 

6/58 

Collins 

6/58 

Anderson Nichols 

7/58 

Smith Corona 


Smith Corona 


Smith Corona 


Anderson Nichols 

7/58 

Anderson Nichols 

1/58 

Ampex 

7/58 

Ampex 

6/58 


Delivery 

Date 


12/59 

1/61 


9/58 

3/58 

10/59 

8/59 

2/60 


2/60 

2/60 

10/59 

1/60 
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i V jtcrr a and programming concepts for the Fiel- 
2t* famiiy of computers at the Moore School of 
yjnf University of Pennsylvama. The six task areas 
jgyofved systems, human factors, data transmis- 
1>M- common languages, new devices, and codes. 

common language effort, led by Saul Gom, 
fcgused on the feasibility of standardized coding 
^thods for families of computers (Sammet 1985; 
0 $ m and Parker 1960). As part of this effort, the 
Automatic Code Translation System (act) ad- 
dressed the problems of writing programs that 
(Ould be compiled and executed on families of dif- 
ferent computers (Holt and Turanski 1960a). A 
tenet of Fieidata was the need for any type 
problem to be run on almost any one of the 
machines. The farsighted nature of the ACT work 
|l best indicated by the statement in their final 
report (Holt et al. 1960b): "that the overwhelming 
majority of Army personnel concerned with these 
problems will not be computer programming ex- 
perts . • • and that the efficiency of the entire 
fieidata system hinges primarily on the speed of 
problem solution— i.e., the total "lapsed time” from 
problem statement till solution delivery.” 

The people who worked primarily on ACT were 
Anatol W. Holt, William J. Turanski, and E. J. 
Parker and they envisioned a system of three parts. 
The first was an allocation interpreter that co- 
ordinated a family of small stored subprograms. 
The second was a library of basic translation 
functions, and the third was a general translation 
library with content that varied depending on the 
application. 

Various other results of this University of 
Pennsylvania work were the development of 
techniques for detailed two-dimensional micro- 
flowcharting of machine instructions, significant 
theoretical work on formal languages by Gom, 
exploration of optimizing techniques for infor- 
mation retrieval using list processing, and hu- 
man factors studies of computer console design. 

The Signal Corps contract at the Carnegie In- 
stitute of Technology was under the leadership of 
Alan Perlis (Perlis 1961). It concentrated on the 
general area of programming languages and 
tranlators and produced, for example, the concept 
of the threaded list. 

Fieidata Standards 

A number of standards were established by the 
neidata program. For example, to ensure that the 
equipment developed by the various manufactur- 


ers could physically interconnect, the voltage lev- 
els, signal characteristics, cables, and plugs were 
specified. For character transmission between de- 
vices, a total of 21 lines was defined, including 
eight data lines, nine monitor and control lines, 
one strobe, one ready, a circuit ground, and a 
chassis ground 7 (USASRDL 1959). 

Standards were also established for the paper 
tape, including the precise hole positions and di- 
ameters, which channels would be used for Bau- 
dot and which for Fieidata bits, and the handling 
of parity errors. The control and data signals and 
their precise specification were also identified, as 
well as the pin numbers for all the interconnec- 
tions (USASRDL 1959). 

The magnetic tape characteristics were also 
defined with channel assignments, control func- 
tions, block formats, and error handling. Specific 
programming standards were established for 
handling blocks, labels, and headers, as well as 
the pin assignments and logical control signal as- 
signments for the electrical connections between 
the tape units and controllers. Provisions were also 
made for the use of nine channels on 1/2 inch 
tape, for error detection codes, and for 13 chan- 
nels on 3/4 inch tape for error correction. There 
is no record, however, that 3/4 inch tape was ac- 
tually implemented (USASRDL 1959). 

The mobidic instruction set itself was an im- 
portant Fieidata standard. At the time it was es- 
tablished, many lessons had yet to be learned about 
machine compatibility, mobidic had 52 basic in- 
structions and the remaining 12 of the possible 
64 were left available for optional use. This, of 
course, meant that any programs that used these 
optional instructions could not be exchanged be- 
tween machines with different implementations. 

Of greater concern was the anomalous behav- 
ior of the MOBIDIC instructions regarding "gar- 
bage results. For example, in the arithmetic op- 
erations, the contents left in the B register 
depended on the values of the various numbers 
involved. In the addition of the number x to the 
A register contents, for example, the number x 
would be left in the B register if the sign of x and 
the sign of the number originally in the A reg- 
ister were equal. If they were different, and the 
magnitude of the number in A was greater than 
or equal to x, then the ones complement of x was 
left in B. Otherwise, B was set to all zeros (Syl- 
vania 1960). This was primarily a problem with 
the arithmetic instructions, but clever program- 
mers could use these capabilities and contravene 
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compatibility unless all the machines in the fam- 
ily reproduced exactly the same anomalous be- 
havior. The need for strong architectural control 
was not sufficiently recognized at the time and 
adequate steps were not taken to insure that all 
the machines in the Fieldata family were pre- 
cisely identical in this respect. As a result, pro- 
gram interchange could not be guaranteed (Chao 
1959: Sammet 1985; Sylvania 1960). 

The Fieldata Code 

Of all these standards, the Fieldata code had the 
most far-reaching implications. Work on this code 
started in late 1956 when Mike Bosch, a member 
of Sylvania’s engineering staff, started designing 
mobidic’s input-output system. He realized that a 
standard code was needed to communicate be- 
tween the I/O devices and the mobidic machine. 
He also knew that no existing code was entirely 
adequate. The mobidic word structure had 36 bi- 
nary bits with an added parity bit and an optional 
sign bit. Bosch decided that the I/O should han- 
dle data in six-bit characters, so he produced a 
preliminary proposal for a six-bit code and re- 
viewed it with his managers, Watts' Humphrey and 
John Terzian. When they reviewed this with the 
Signal Corps, Luebbert and his staff quickly saw 
that this code had far broader implications. 

After some further study, Luebbert and his 
people realized that some compromises between 
the needs of a computer code and those for com- 
munications were required. For example, the large 
Signal Corps inventory of teletype equipment 
meant that the new code should be transmittable 
over teletype systems. The first six characters in 
the Baudot teletype code, in both upper and lower 
case, were used for the following control func- 
tions: master space, upper case, lower case, tab, 
carriage return, and space. All teletype machines 
would interpret these characters as control func- 
tions and any Signal Corps communications code 
would have to provide for this or be incompatible 
with the large inventory of installed teletype 
equipment. The result of these studies was the 
Fieldata code which is described in Appendix A 
(Luebbert 1985; USASRDL 1959). 

MOBIDIC 

Sylvania and Computers 

Sylvania, until it became a subsidiary of the Gen- 
eral Telephone Company, had been a modest-sized 


electronics company with several facilities in the 
Boston area. The company started around the turn 
of the century refilling used General Electric li ght 
bulbs and reselling them. From there, its busi- 
ness grew to include the manufacture of light 
bulbs, vacuum tubes, radios, television sets, and 
a range of electronic components. 

In 1946, Sylvania established an electronics 
development group to assist in the Whirlwind 
computer development at MIT (Sokol 1967). In the 
10 years that followed, this group was involved in 
many developments concerning computers, digi- 
tal communications equipment, and sophisticated 
communications systems. They participated in the 
numerical control computer work at MIT, the sage 
early warning system, and several digital cryp- 
tographic communications devices. 

In early 1956, Sylvania’s electronics develop- 
ment organization was located in a large labo- 
ratory overlooking Route 128 in Waltham, Mass. 
It was entirely devoted to military equipment 
contracts but a small group eagerly sought in- 
volvement in general-purpose computer develop- 
ment. The demands of the recently awarded BMEW8 
(Ballistic Missile Early Warning System) and the 
countermeasures electronics development for the 
B-58 Hustler supersonic bomber were substan- 
tial, however, so there was heavy pressure to 
reassign the computer engineers to these high- 
priority projects. 

The small Sylvania computer group was headed 
by Fred Anderson with two departments under 
George Sokol and Watts Humphrey. Work of this 
type was running low at that time, however, and 
no new digital development contracts were on the 
horizon. The limited Sylvania electronics sales 
force had searched for likely digital equipment 
contracts, and one day the call came that the Na- 
val Training Devices Center in Port Washington, 
New York had sent out for bids on a Universal 
Digital Operational Flight Trainer (udoft). udoft 
was to interchangeably control F9F or F104 air- 
craft simulators in real time. The navy sought the 
flexibility of an easily changed stored-program 
machine, but the required performance was sub- 
stantially faster than any machine then avail- 
able. Humphrey met with the navy contract peo- 
ple who doubted that Sylvania could submit a bid 
in the two weeks remaining before the deadline, 
but they finally agreed to let them try. A few days 
later, word came of the Signal Corps’ procure- 
ment for mobidic, a transistorized, rugged, large- 
scale, general-purpose digital computer. 

After an enormous crash effort, both the UDOFT 

/ 
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[ %S A mobidic bids were submitted on time. The 
-gyp then went back to work to finish the ex- 
contracts. Soon, all work in Humphrey’s 
—gyp was essentially completed, and Sylvania 
r judgement decided to disband the organization 
JjJd reassign the people to the bmews and Hustler 
projects. After much argument, Anderson con- 
duced them to wait until the navy and Signal 
Carps decisions were made on the udoft and 
MOBIDIC proposals. In late summer of 1956, Syl- 
**nia was awarded contracts to develop both of 
these computers, and an organization had risen, 
like a phoenix, from the ashes. 

The initial development work on the mobidic 
and UDOFT machines was handled by Humphrey’s 
group. Three early recruits to this effort were John 
Terzian from MIT’s Lincoln Laboratory, Ed Coh- 
Jer from MIT, and Mike Bosch. Terzian handled 
the mobidic logical design and Cohler was put in 
charge of the circuit design for both mobidic and 
IDOFT. Bosch became a key architect working with 
Tertian on mobidic. Over time, these depart- 
ments grew and many more people were added. 
The circuit design group at various times in- 
cluded A1 Ashley, Tom Baker, Greg Prom, Mike 
Stern, Jo Tucker, and Herb Ullman. The logic de- 
sign group, in addition to Terzian and Bosch, in- 
cluded Herb Brun (hired when he completed his 
enlistment in the Signal Corps), Stanley Chao, and 
Charming Morrison. 

A programming activity was also established 
under the initial direction of Arthur Wouk and 
later managed by Carl Hammer and then Norm 
Zachary. Jean Sammet initially managed the 
software work for mobidic, including a software 
simulator on the 709. When she became heavily 
involved in the COBOL committee efforts, Sid 
Cashton became responsible for the mobidic soft- 
ware development. Many other people were in- 
volved in the mobidic program at various times, 
including Ray Castiglione, A1 Fullerton, Ray 
Gazzola, Mel Haven, Bob Hinds, Ed Jervis, Joe 
Parziale, and Harvey Tzudiker (Cohler 1985- 
Sammet 1985; Sokol 1967). 

As the hardware development organization 
grew, it was divided into various departments but 
the key management roles continued to be held 
- Soko1 and Humphrey under the overall man- 
agement of Anderson. Humphrey was in charge 
sf system and circuit design and Sokol ultimately 
became overall program manager for all of Syl- 
vama’s mobidic work. In addition, Cohler, Jervis, 
and Terzian also headed major portions of the 
various projects. The entire organization ulti- 


mately became too large to stay in Sylvania’s 
Waltham location so it was moved to its own lab- 
oratory in Needham, under the overall manage- 
ment of Eugene Vigneron. It was here that the 
bulk of the design and manufacturing was done 
for the mobidic computer family. 

Though the udoft and mobidic computers were 
both completed essentially on time and within 
budget and they were technically successful, nei- 
ther program had any lasting impact on Syl- 
vania. The company was hesitant to take on the 
enormous risks of the highly competitive com- 
puter business. After the mobidic contract award 
for example, mobidic would have seemed the log- 
ical choice for the bmews computers. This system 
required a network of radars and computers in an 
arctic defense line, and machines were required 
that used minimum power, had the highest pos- 
sible reliability, and needed a- minimum of envi- 
ronmental protection. Unfortunately, Sylvania 
management was unwilling to seriously consider 
mobidic, even though its schedule was consistent 
with bmews requirements. Initially, IBM 709 
computers were selected and these were ulti- 
mately upgraded to the transistorized IBM 7090 
machines before bmews installation. 

During the period from 1957 to 1960, a number 
of Sylvania internal proposals were made for the 
commercial exploitation of mobidic. In one 
(Humphrey 1957), a comparative table of perfor- 
mance was given for mobidic and some of the then- 
available commercial machines. As can be seen in 
Table 2, mobidic was an exceptionally high-per- 
formance machine for its time. 

Sylvania finally decided in 1960 to make a 
commercial offering of mobidic. Other high-per- 
formance transistorized commercial machines had 
already been introduced by that time, however, 
and many of the key computer people had already 
left Sylvania. Humphrey was the first to go in 
1959 when he left Sylvania for IBM. Over the next 
few years, many of the other MOBIDIC developers 
left to work for other organizations in the com- 
puter field including Cohler, Hammer, Morrison, 
Sammet, Terzian, Wouk, Zachary. 

The commercial version of mobidic was called 
the Sylvania 9400 and it had even higher perfor- 
mance. Because of mobidic’s conservative circuit 
design philosophy, the machine could be reliably 
operated at 2 megahertz and the memories could 
be speeded up to a 4-microsecond cycle instead of 
eight. This doubled mobidic’s internal perfor- 
mance and produced a highly competitive ma- 
chine that used the mobidic architecture, instruc- 
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Table 2. mobidic Competitive Evaluation 


Computer 

Speed's 

Memory 

I/O 

Price 

Data 

Arith. 

Size 

Access 

Rate 

IBM 705 III 

18.3 

4.27 

48,000 

17 

360 

1,900 

IBM 709 

32.7 

.48 

114,688 

12 

80 

1,803 

MOBIDIC 

21.2 

.246 

100,352 

8 

315 

1,340 

Basicpac 

21.2 

.872 

28,678 

8 

315 

960 

650 Tape 

145.7 

37.84 

7,180 

96 

15 

560 

Datatron 

79.7 

9.3 

30,000 

15 

25 

762 


Notes: Data speed — time, in milliseconds to read 500 characters from tape and compute 
check sum; arithmetic — time in milliseconds to perform a sequence of arithmetic operations; memory 
size— the maximum addressable characters; memory access — the memory access time in mi- 
croseconds; I/O rate — theoretical maximum I/O transfer rate in characters kc; price — the price 
of the minimum machine in $000 with printer and four tapes. 


tion set, and circuits. Some changes were made 
in the indexing system, error handling, I/O in- 
structions, physical cabinetry, and console layout, 
however, to make the machine more competitive, 
and correct some of the deficiencies that had been 
noted in the Signal Corps machines. The basic 
machine architecture and design, however, were 
unchanged. 


Time, however, was of the essence, for the com- 
mercial computer field was moving rapidly and 
there was little time for vacillation. IBM’s recent 
announcement of the specifications for its Stretch 
computer created quite a stir among the Sylvania 
computer engineering fraternity. One group pro- 
duced a specification for a competitive machine, 
humorously called Scrunch (Figure 4). 


Speea. for Scrunch Computer 

».t 1134,235,432.25 (plu ind lundllng - add 504 In 
word length - 120 digit* 

C*p*clty - 5 trlgablt. 3 yl.«nl» 

Trldycchronous oj»r*tlon Connordtlon* 

B**lc Operating Term* Reatlv 

Add - 0.1 millimicroseconds Oaalaaa 

Subtract - 0.1 millimicroseconds Numerical 

Multiply - 0.25 millimicrosecond# Calculating 

Divide - 0.35 mill lml croaeconda Heap 

Memory Cycle - 0.05 mil 11ml croaeconda 

•add 0.005 millimicrosecond If transferred over bua 

note: 0.1 ailllmlcroaecond - 3 light centimeters 
Physical dimensions 

Overall (including power supply) - 5.0 liters (also available In 
ruggedlzed form - 5 x 10 ® cu. ft.) 

Power Requirements 

♦ 8 Vdc • 37 aa. 

- 8 Ydc • 36 as. 

± -1 Vac • 100,000 kl . . .. . 

♦ SO Vdc • 100 aa J wlth *«dlc*tors 
In -Out Equipment 

English to Russian *) . 

Russian to Sanskrit/ Translator 
Portable Typewriter 

Serial Orbital Transfer Control (optional for Satellites) 

20,000 llne/see direct printout (Sears k Roebuck) 

D- A - D Converter fMillman A Taub) 

M-O-M Converter (opposite of D A D converter) 

Tape -Reader 
Card -Reader 
Book Reader 
Clock Watcher 
IBM-704 
Hammond Organ 

furlong- to -Pa thoa converter (direct) 

Light -feet -to -Millimicrosecond Converter (indirect) 

Reason for Construction - Moral Obligation 
Order Code - Not necessary 
Circuit Properties 

Convergence factor - w 
Pyramid factor - « 

Cascading factor - n" 

Clock source - white noise 
Estimated delivery date - February 29, 1984 
Logical system - Haven't thought about it much 
Arithmetic Operations 
fixed point 
Plotting point 
S ink i n g point 
Dew point 

Don't point (for Scrunch Jr.) 


Round Off Operation 

All but Dost significant bit 
Number base 

Modulo 17 

Basic Circuit Characteristics 

Anticipated fall tics (happens before rise ' 
POT) 

Political Advantage 

"It floats " (99-44/100* pure) 

Prime Power - Natural das 

Physical Construction - Enclosed in Black Box 


i - use NPN instead of 


Figure 4. Specification for the Sylvania Scrunch computer. 
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gy the time of the 9400 computer announce- 
ment Sylvania had become a subsidiary of Gen- 
Teiephone. The first 9400 computers were or- 
fcred by the General Telephone and Electronics 
C&np&ny (GTE) of California and several more 
<J#t j er 3 were anticipated. Unfortunately for the 
U^jBiOiC advocates, Sylvania’s recently acquired 
igjjryessive attitude was only at the local level and 
gdrporate headquarters still had cold feet. They 
gjsessed the likely costs of entering the computer 
field and decided it was both too risky and ex- 
pensive. The decision to market the 9400 was thus 
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rescinded and only two machines were ever built 
(Sokol 1967): one was leased for several years by 
the Pentagon’s Office of the Assistant Chief of 
Staff for Intelligence and the other was used for 
business data processing in Sylvania’s electronics 
development organization. 

The decision to rescind the 9400 announce- 
ment was publicly disclosed to the Sylvania Lab- 
oratory in Needham, Mass, on December 23, I960 
(Figure 5). This was a bitter Christmas present 
for the computer development people, and their 
reaction is best expressed by the satirical parody 


* ☆ ☆ EXTRA! * * 

NEEDHAM 

SYLVAN,A NEWS 




SPECIAL EDITION 


Friday, December 23, 1960 


The following open letter to DSO employees was released to the Needham Sylvania 
News today by General Manager E. J. Vigneron. 

TO ALL EMPLOYEES: 

, , , 1 l ° 0pp0r,mut y to you of recent decision, regarding onr 

Sylvania 9400 computer program. 

Earlier, it had been annoonced that the Sylvania 9400 marketing program woold inclod 
operating telephone companies as well a. the Federal Government. This annnoneement created 
a very erroneous impression of the company's intent in the dam processing Held bv tallvi^ 

— “ *“ riSk ' ntry im ° COmpetiUv ' "««=*" Challenging the leader^ 

in the field. Smce the effect of this erroneous impression is so adverse to the company in 

ad ° P ' ‘ ° f iCtl ° n W “ Ch «— ” intent 

toward rSSLTZZir.-t ^ '"° rt6 " — * ole ‘y 

tarized data oroIT, recognized and is the leader in producing mili- 

ar, zed data processing equipment. I„ conformance with this decision, the 9400 which had 
been ordered by General Teiephone of California is now cancelled. 

This decision should be regarded a, a change in the direction of our efforts rather than 
any serious loss of business volume. The General Telephone of California order it.T 

“ ~ — - — • - 

neat yoor'^ReceiiUy^^particiiMted'witi^mentfwr^of'tJieHigiiisl Corps'in^th^Penagon and'"* 88 
™l M °Zyt ta diSCUS r Var: ° US PrOPOSalS ” *" for “proved Fieldaa equip- 

orders ^ ‘ ^ - P — ~ 

of work Unread qUi ‘' ""“T ““ ““ — « m » substantial amount 

° f r “ d ° V " * nhnsiderable period of time. Actually, the demand for da a processing 
equipment our markets is continuing to Increase all the time We still of course h, 

"rs" 1- — ■ ~~ ~ — - - M^Thirri 

1.0^;,: Uk.T»iL a l a LT ' BD ‘ 7 “ d PARADE ' for us. 

old also like to pornt out that recently our technical mission has been enlarged and we 

have been given additional manufacturing responsibility. 

looking fo“m m b e' ° P,i ”‘ S ' iC ab °“‘ OUr ‘ h ° P ' with me in 

king forward to the many opportunities that are ahead for us in data processmg. 

Chris.™,' ” *' to y °“ “ d “y »-hes for a very Merry 


Figure 5. E. J. Vigneron letter. 
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of the official announcement letter that was dis- 
tributed through the Sylvania engineering grape- 
vine (see Figure 6). 

mobidic Architecture 
Basic Approach 

mobidic was a parallel-binary single-address von 
Neuman class machine. It used a double-bus mod- 
ular structure to allow for a variable number of 
memories, I/O channels, and special registers. The 
architecture made all of the registers address- 
able, used no special modes of operation, and de- 
signed the I/O controllers to be fully transparent, 
that is, the I/O devices were directly addressable 


* * * fEJSTTmi\£ 


RICHMOND 

CONFEDERATE 



ii 


•A v' 

and could be accessed through any available I/O 
controller. MOBIDIC was designed as a fully asyn- 
chronous machine with no internal operations that 
depended on the speed of the timing clock. Al- 
though this did not include the timing-sensitive 
I/O devices that were handled by the I/O con- 
trollers, it did permit the machine to operate from 
one-megacycle speeds all the way down to oper- 
ator-controlled single stepping. The specific char- 
acteristics of mobidic are shown in Table 3 (Syl- 
vania undated). 

Machine Structure 

The basic logical organization of mobidic is shown 
in Figure 7 (Sylvania undated). The main trans- 


tr & ☆ 


SPECIAL EDITION 
April lit, 186$ 



The following open letter to Confederate troops was released 
to the HIGHMCHD CONFEDERATE NEKS today by Ccmmander-in-Chief, R. E. Ice. 

TO ALL TROOPS* 

I would like to take this opportunity to inform you of recent 
decisions regarding our Southern Independence program. 

Earlier It had been announced that the Southern Independence 
program would include 11 Southern states as well aa the city of Richmond* 
This announcement created a very erroneous impression of our group's 
intentions in the independence field by Implying that we intended to 
actually set up a government challenging the leaders in the independence 
business. Since the effect of this erroneous impression is so adverse 
to our group in general, it has been decided to adopt a curse of action 
which would leave no doubt as to our intent in this line of endeavor. 

Accordingly, our group will now direct its efforts in the 
independence field solely in the Richmond market where it is well 
recognized and accepted and is the leader in independence. In conformance 
with This decision, the independence which had been ordered for 
11 Southern states is now cancelled. 

The decision should be regarded as a change In the direction 
of our efforts rather than as aiy serious compromise of our principles. 

The 11 Southern states amounted to something leas than 100jS of our 
plan, and vo see no immediate effects of its cancellation, other than 
imprl sonment . 

I would also like at this time to tell you seme of our prospects 
for new Independence next year. Recently I participated with representa- 
tives of several South American states in discussing various proposals 
for offering improved independence. They are very enthusiastic about 
our ideas, and I believe they will be starting some rebellions in 
their countries in the very near future. V*e axe quite confident about 
what remains of the Richmond program and believe that this will result 
in a substantial amount of work spread over a considerable period of 
time. Actually the demand for independence is continuing to increase 
all the time. 

I continue to be very optimistic about the future. I hope that 
you will join with me in looking forward to the many opportuni tiea 
that are ahead for us. 

Let me, at thi3 time, extend to you and you r families my wishes 
for a very Horry Appomattox Day. ^ . ^ 



Figure 6. Spoof of Vigneron letter. 
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Table 3. mobidic Basic Characteristics 


System Organization 
Word Structure 


Word Length 
Core Memory 
Magnetic Tapes 
Simultaneous Tapes 
Teletype Units 
Paper Tape Readers 
Other In-Out 


System Features 

Index Registers 
Real-Time Registers 

Operating Speeds 

Addition/Subtraction 

Multiplication 

Division 


Binary Fixed-Point 
Fractional Magnitude 
and Sign 

38 Bits 
4,096 Words 
2 
1 
1 
1 

1 Tape Punch 


16 microseconds 
86 microseconds 
88 microseconds 


Expanded 


38 Bits 

28,672 Words 
S3- 3 
4 
63 a 
63 a 

Flexowriter 
Card Read-Punch 
Line Printer 


No Practical Limit 


A maximum of 63 standard input-output devices could be connected to mobidic. 


fer bus carried all instructions and data to and 
from the various registers, memory, and I/O. It 
had 38 parallel lines and was connected to every 
register in the machine. 

The entire system was controlled by a single 
clock timer which emitted 1-megacycle timing 
control pulses. This stream was split into alter- 
nating p and t pulses, each spaced at 2-microse- 
cond intervals. A sequence of eight timed gate 
levels were provided with nominal 2-microsecond 
duration, synchronized with the t pulses. These 
signals, TF-1 through TF-8, could be extended be- 
yond 2 microseconds whenever long-duration in- 
structions or certain special machine functions 
were to be performed. This was done by setting 
the lambda control flip-flop to one. 

In addition to the memory, arithmetic, and 
' ® operations which will be described in more 
detail below, the other registers performed the 
following functions: 

Program Counter: A 15-bit binary counter that 
held the address of the next instruction to be taken 
from memory. Depending on the number of mem- 
ory units attached, the program counter auto- 
matically cycled from the highest physical ad- 
dress m the machine to the all-zeros address. 

Address Register: A 15-bit register to tempo- 
fanly store the address specified in the instruc- 


tion until it was needed for memory access. When 
indexing was used, the contents of the referenced 
index register were added from the bus into the 
address register to form the operand address. 

X-Register: A 12-bit register that provided 
storage of the beta part of the instruction word. 
The use of these bits is described later under "In- 
struction Format.” 

G-Register: A 3-bit register that stored the 
gamma bits that were used to identify the index 
register used in the instruction. 

Index Registers: Up to seven 12-bit index reg- 
isters could each hold an address increment or be 
used as a cycle counter for program loop control. 

T-Counter: A 7-stage counter that controlled 
shifting operations and various other counting 
functions required by the arithmetic instructions. 

Program Counter Store: Used to temporarily 
hold the program counter contents during a 
transfer of control operation. It was the address 
to which control was returned by a "transfer to 
PCS” instruction. 

Instruction Register: A 6-bit register that held 
the 6-bit operation code until it was needed for 
instruction control. It was then transferred to the 
decoder register where it controlled the sequence 
of the logical steps needed to execute each in- 
struction. 
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Figure 7. mobidic logical organization. 
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mobidic Word Formats 

The format of the four types of mobidic words is 
shown in Figure 8 (Sylvania undated). 

Numbers in mobidic were represented by 36- 
bit fractional binary numbers with sign and odd 
parity. The binary point was assumed between bits 
36 and 37 and a positive number was represented 
by "0” in bit 37, the sign bit. 

For alphanumeric data, the 36 rightmost bits 

into an index register as the starting point for 
counting, or, together with the three gamma bits, 
make a full second operand address. 

Bits 28 to 30 were the gamma bits that speci- 
fied one of the possible seven index registers in 



NUMERICAL DATA 

PARITY SIGN 


MAGNITUDE 




were divided into six characters with the sign bit 

1 38 1 37 

36 



— n 



unused, again with odd parity. Several of the 
mobidic instructions were designed to manipu- 
late these individual characters within the mob- 

ALPHA NUMERIC DATA 

PARITY SPARE 


SIX a/N CHARACTERS 



idic word for such operations as sorting and code 

38 37 

36 



— 1 

■ 


translation. 

The standard mobidic instruction had 36 bits 
plus odd parity. Bits 1 through 12 of the alpha, 
or address field, specified a location within a given 
4,096-word memory while bits 13 to 15 desig- 
nated the registers or one of the seven possible 
memories. 

The 12 beta bits, 16 through 27, could incre- 
ment an address in an index register, be loaded 

STANDARD INSTRUCTIONS 

PARITY SPARE 

OP 

CODE 

y 

e 

0 



38 37 

36 31 

30 28 

27 16 

13 !| 

- 


IN-OUT INSTRUCTIONS 

PARITY SPARE 

OP 

CODE 

k 

j 

a 


- 

[ 36 37 

36 31 

30 22 

21 16 

Ts rj 



Figure 8. mobidic word format. 
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y address. An all-zero gamma indicated no in- 
fri register was to be used. 

31 to 36 specified one of* tbe 64 operation 
,.. 4 ^ for the instruction. 

|n input-output instructions, word segments j 
jpd 4 replaced beta and gamma. Their functions 
0ttt- 

»— -Bits 16 to 21 specified which one of the 63 
pisfcsibie input-output devices was to be used in 
ti* instruction. 

4 — Bits 22 to 30 specified the number of words, 
jjjocks, cards, or lines to be processed by the in- 
jlruction. 


a vcexMC Basic Cycle 

Ifce operation of the mobidic machine was con- 
trolled by the eight TF timing functions. TF-1 
through TF-5 were common to every instruction 
since they included accessing and rewriting the 
instructions and operands in the magnetic core 
memories. TF-6, TF-7 , and TF-8 were specialized 
to particular instructions. The functions shown in 
Table 4 are those required for the ADD instruc- 
tion (Sylvania undated; Sylvania 1959a). 


The mobidic Arithmetic Unit 


The mobidic arithmetic unit had three registers, 
A, B, and Q, as well as controlling logic for the' 
arithmetic operations. The A, or accumulator, 
register held the augend, minuend, multiplicand, 
or dividend at the start of addition, subtraction, 
multiplication, or division, respectively. At the 
conclusion of these operations, it held the nu- 
merical result except in division where it con- 
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tk* instruction or, together with beta, formed a 


tamed the remainder. The B register initially held 
the addend, subtrahend, multiplier, and divisor 
for these same operations. The Q register held the 
multiplier and the low-order bits of a double-length 
product in multiplication. In division, Q started 
with the low-order bits of a double-length divi- 
dend and ended holding the quotient. This reg- 
ister was also used as a mask for the MSK in- 
struction and could also be joined with the B reg- 
ister for double-length shift and cycle operations 
(Sylvania 1960). 


The mobidic Instruction Set 


The six operation code bits in the mobidic in- 
struction word allowed for 64 instruction types, 
summarized in Table 5 and described in more de- 
tail in Appendix B (Sylvania 1960). 

The mobidic instruction set was, in many ways 
of a relatively straightforward design, but it did 
have a few unique characteristics. John Seymour, 
who was a mobidic programmer, also worked with 
Sperry Rand and IBM machines, and he describes 
the mobidic instruction set as powerful, yet small 
enough to easily learn and remember. He adds that 
the I/O instructions were simple and convenient 
and the error-handling system was "pretty neat.” 
The repeat instruction, however, he found to be 
unusually powerful. It could be used with the store, 
move, or compare instructions to perform very 
powerful functions. Seymour used the repeat- 
compare sequence, for example, to compute the 
arcsine by a simple table look-up and expansion 
method that was faster and more accurate than 
e has seen with any other computer before or 
since (Seymour 1985). 


Timing Functions 


Table 4 . mobidic Basic Cycle 


Operations 


1. Operand Arrives at Memory Output Register 

1. Rewnte Operand in Memory 

No basic cycle operations performed 

J* p5! H S, I r , PC . Co " tents t0 Memory Address Register 

2 . Read Pulse to Memory 

1. Next Instruction at Memory Output Register 

2. t£&, SS°" EkimertS to Address ' *• a « instruction Resistors 

1. Step PC 

f Trt d nc^ Si r na l ed * lnd f X Register Contents to Address Register 

2 . ' Re .0 ?uSo e Memo“ r9SS Re9iSte ' " “ em °' y Meas Re 3 iae ' 

3. Transfer Instruction Register Contents to Decoder and Decode 
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Table 5. mobidic Instruction Summary 


Octal 

Code 

Operation 

Abbrev. 

Operation 

Address 

Fields 

Indexable 

00 

HLT 

Halt 


No 

01 

RPT 

Repeat 

y0“ 

Yes 

02 

LGM 

Logical Multiply 

ya 

Yes 

03 

LGA 

Logical Add 

ya 

Yes 

04 

LGN 

Logical Negation 

ya 

Yes 

05 

SEN 

Sense 

y0“ 

Yes 

06 

SNS 

Sense and Set 

y0a 

Yes 

07 

SNR 

Sense and Reset 

70“ 

Yes 

10 

CLA 

Clear and Add 

7“ 

Yes 

11 

CAM 

Clear and Add Magnitude 

ya 

Yes 

12 

ADD 

Add 

70“ 

Yes 

13 

ADM 

Add Magnitude 

70“ 

Yes 

14 

CLS 

Clear and Subtract 

ya 

Yes 

15 

CSM 

Clear and Sub. Magnitude 

7“ 

Yes 

16 

SUB 

Subtract 

70“ 

Yes 

17 

SBM 

Subtract Magnitude 

70“ 

Yes 

20 

MLY 

Multiply 

7“ 

Yes 

21 

MLR 

Multiply and Round 

7“ 

Yes 

22 

DVD 

Divide 

70“ 

Yes 

23 

DVL 

Divide Long 

70“ 

Yes 

24 

ADB 

Add Beta 

70a 

No 

25 

26 

SBB 

Subtract Beta 

70a 

No 

27 

30 

SHL 

Shift Left 

70“ 

Yes 

31 

SLL 

Shift Left Long 

70“ 

Yes 

32 

SHR 

Shift Right 

ya 

Yes 

33 

SRL 

Shift Right Long 

ya 

Yes 

34 

CYS 

Cycle Short 

ya 

Yes 

35 

36 

CYL 

Cycle Long 

ya 

Yes 

37 

NRM 

Normalize 

ya 

Yes 

40 

TRU 

Uncond, Transfer 

70“ 

Yes 

41 

TRL 

Load PCS and Transfer 

70“ 

No 

42 

TRS 

Transfer to PCS 

No 

43 

TRX 

Transfer on Index 

70“ 

No 

44 

TRP 

Transfer on Positive A 

ya 

Yes 

45 

TR2 

Transfer on Zero A 

ya 

Yes 

46 

TRN 

Transfer on Negative A 

ya 

Yes 

47 

TRC 

Compare 

ya 

Yes 

50 

STR 

Store 

ya 

Yes 

51 

LOD 

Load 

y0“ 

Yes 

52 

MOV 

Move 

70“ 

No 

53 

LDX 

Load Index 

70“ 

No 

54 

RPA 

Replace Address 

7“ 

Yes 

55 

56 

MSK 

Replace through Mask 

ya 

Yes 

57 

60 

61 

62 

63 

64 

65 

66 

SKP 

Skip 

kj 

No 

67 

BSP 

Backspace 

kj 

No 

70 

RAN 

Read Alphanumeric 

kja 

No 

71 

RRV 

Read Reverse 

kja 

No 

72 

73 

ROK 

Read Octal 

kja 

No 

74 

WAN 

Write Alphanumeric 

kja 

No 

75 

WWA 

Rewrite Alphanumeric 

kja 

No 

76 

WOK 

Write Octal 

kja 

No 

77 

RWD 

Rewind 

i 

No 
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frjtfxnc Mode 

, .vjjpic had a trapping mode to assist program* 
in debugging. When the flip-flop, TRA, was 
, the machine would automatically change the 
‘•jence of instruction execution when any of the 
M trappable instructions were encountered, 
were TRL, TRS, TRX, TRN, TRP, TRZ, SEN, 
>SS, and SNR. Under these conditions, the in- 
0 W & ion was not executed, the program counter 
grants were put in the B register, and control 
transferred to memory location O. The TRA 
fhp-flop was set anc * c ^ eare d by using the transfer 
biconditional (TRU) instruction together with 
CtiiAin combinations of bits 16 and 17 in the TRU 
gaSruction. Since beta was not used in TRU, these 
^ served no other purpose. 

Trapping was controlled by the TRA flip-flop 
gad bits 16 and 17 of every TRU instruction con- 
fpjUed trapping in the following way: 


tTRAM016)’ = 
016X017)’ = 
016X017) = 


Trapping occurred 
TRA set 
TRA reset 


Therefore, if the programmer did not intend to 
trap, bits 16 and 17 of the TRU instruction were 
get to l’s. Furthermore, there was a TRA switch 
an the mobidic console to inhibit all transfers to 
trapping mode when it was set to "off.” 


Error Conditions 

MOBIDIC was designed to ignore any nonexistent 
addresses or instructions. For example, if a non- 
existent memory address was referenced, the ma- 
chine would halt or not depending on the setting 
af the KEW (kill error) switch. If the nonexistent 
address was used in an instruction, the contents 
was assumed to be zero. A nonexistent address in 
an instruction was treated as a no-op. When con- 
trol was transferred to a nonexistent address, the 
instruction counter would continue to count out 
no-op instructions until a valid memory address 
was reached and program execution would then 
continue. Because of the memory structure, this 
first valid address was address 0, or the same lo- 
cation that the trapping mode transferred to. 

Wnen a nonexistent index register was refer- 
enced, its contents were assumed to be zero and 
none of the real index register contents were 
changed. The same was true for references to 
nonexistent sense flip-flops. 


The mobidic I/O System 

I/O Architecture 

The basic structure of mobidic’s I/O operations 
was described in Sylvania’s patent on the MOBIDIC 
system (Terzian et al. 1965). Figure 9, from this 
patent, shows the structure of the MOBIDIC I/O 
operations. The I/O Converters [124] all attached 
to the main transfer bus [100] and each converter 
had its own converter bus [118] to connect to all 
the I/O devices. Each such device had a set of 
device switching units (DSU) to connect it to the 
converter bus. 

The I/O system was designed to automatically 
select a free converter every time the computer 
initiated an I/O instruction. Since each converter 
could access every I/O device, the programmers 
did not have to control converter selection. Once 
an I/O instruction was given, the MOBIDIC main 
processor passed the needed control information 
to the first free converter which then managed 
the I/O operation, while the computer continued 
with normal program execution. When needed, the 
MOBIDIC instruction stream was interrupted briefly 
for a memory access, but, except for errors, there 
was no other processor interference until the I/O 
operation was completed, mobidic could execute 
as many simultaneous I/O operations as it had 
converters. Because of timing constraints, how- 
ever, only four magnetic tapes could be read or 
written at the same time. A more detailed de- 
scription of the MOBIDIC I/O system is given in 
Appendix C. 

Instruction Modification 

Since the mobidic system allowed register con- 
tents to be modified, it was possible to modify 
I/O instructions during execution. This could be 
done by changing the contents of the converter 
instruction register (CIS) (not shown), which would 
permit, for example, the writing or reading of long 
blocks of information. I/O instruction modifica- 
tion was described in the mobidic manual as a 
risky operation, particularly during magnetic tape 
operations, because it was possible to destroy in- 
formation or cause unpredictable device behavior 
(Sylvania 19596). 

To change an I/O instruction, the CIS had to 
be changed exactly at the point when the con- 
verter buffer register was empty and before the 
next character or word was placed in it. This point 
could be sensed under program control and then 


Annals of the History of Computing, Volume 9, Number 2, 1987 




mobidic could be programmed to immediately load 
the desired information into the CIS register be- 
fore the next word was entered into or taken from 
mobidic memory. If the CIS register was not 
changed within this interval, the memory address 
and word count would be improper. 

The mobidic magnetic tapes had a recording 
density of 280 bits per linear inch and a transport 
speed of 150 inches per second which resulted in 
42,000 characters per second or approximately 24 
microseconds per character. For six-character 
words, there were thus 144 microseconds between 
word transfers to and from MOBIDIC during which 
the CIS register could be loaded with new infor- 
mation. Because of variations in device perfor- 
mance, however, some tolerance had to be al- 
lowed and the mobidic manual suggested that 
modifications be completed in less than 120 mi- 


croseconds. Considerably more time was avail- 
able with slower devices. 

Ray Gazzola, who was with the MOBIDIC 7A 
group in Germany, reports that instruction mod- 
ification was used extensively in that installa- 
tion. Because of their problems with the magnetic 
tape transports, they took extensive recovery pre- 
cautions to guard against having to repeat their 
six- to seven-hour production runs. They would 
write out all of MOBIDIC core in a single block on 
a dedicated magnetic tape every time there was 
a tape mount. Because the maximum block size 
that could be written with mobidic instructions 
was 512 words, instruction modification was used 
to write the longer blocks. In the event of trouble, 
they would reload core, again using instruction 
modification, and restart at the point where the 
most recent tape mount occurred (Gazzola 1985). 
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ftji-Time I/O 

^ re a!-time system was designed to transfer 
-nchronous data between the MOBIDIC com- 
and other devices. As shown in Figure 10 
j an et al. 1965), it includes a 40-bit real-time 
vV t register (RXR) [134], a 40-bit real-time out- 
» T» register (ROR) [136], and various control and 
c ] r cuits. Bits 38 to 40 were used for special 
3i (r ol functions and a 15-bit real-time address 
*' n ’! {€r (RAR) (not shown) specified the mobidic 
pjQry address to or from which data transfer 
”^5 to start. Both the ROR and RAR were ad- 
dressable by mobidic instructions over the main 
-M.niter bus. The connections to the external de- 
fs^es were over 11 conductor cables: 

JJnes 1—6: Data 
Line 7: Control bit 
Line 8: Parity 
Line 9: Strobe 
Line 10: Ready line 
Line 11: Common ground 


The real-time system had three modes of op- 
eration: noninterpret sign mode, control charac- 
ter mode, and interpret sign mode. For real-time 
input operations, the RAR was first set by the 
mobidic program and then each assembled word 
was stored in the specified memory location and 
the RAR incremented. Eight-bit characters were 
received and packed into 37-bit mobidic words in- 
dependent of the machine’s program, with the only 
interference being the time required for memory 
transfer. Except for the various alarm and inter- 
rupt conditions, there was no other interaction with 
mobidic. More details on real-time operations are 
contained in Appendix D. 

Though these facilities appear, even today, to 
be quite useful, there is no record of their being 
used in any of the actual mobidic installations. 

I/O Alarm and Halt Conditions 

mobidic provided a number of facilities for han- 
dling I/O alarms and error conditions. Each con- 
verter had six in-out alarm (IOA) flip-flops (Syl- 



Figure 10 . mobidic Real-Time System. 
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Vania 19596), which were set whenever any of the 
other five flip-flops indicated error, and its status 
could be sensed and changed by the MOBIDIC pro- 
gram. The five other alarm flip-flops were not 
addressable and ail were cleared whenever the 
converter IOA was cleared. The converter IOAs 
were displayed on the mobidic control console but 
the status of the five individual alarms could only 
be found by looking under the cover of the indi- 
cated converter unit. 

The device alarm (DVA) flip-flop indicated an 
unspecified device failure such as power outage, 
tape breakage, or the physical end of tape. The 
converter halted on the occurrence of this error 
and the central processor was also halted after it 
completed any other in-out instructions in prog- 
ress. 

The no halt on converter error (NHC) flip-flop 
could be set by mobidic under program control and 
it controlled converter action in the case of the 
remaining alarm conditions. When an instruction 
was transferred to the converter, it sensed the 
status of NHC and set its NH flip-flop accord- 
ingly. When NH was reset and an error condition 
occurred, the central processor was halted and the 
converter IOA on the console was lit. The four 
other alarm conditions behaved as follows: 

1. Improper order alarm (IMO) flip-flop was set 
when an improper I/O was encountered, an il- 
legal device was addressed, or an improper ad- 
dress or count field was used. IMO was set and, 
if NH was also set, the order was ignored and 
the converter and device were not connected. 
This condition could be caused by an improper 
order being transferred from mobidic or by an 
improper program modification of CIS. 

2. Interpret parity error (IPE) flip-flop was set 
when a parity error was detected. If NH was 
set, converter and mobidic operation pro- 
ceeded without interruption. 

3. Interpret sign error (1SE) flip-flop was set when 
some character other than a Fieldata one or 
zero was found in the sign field. NH behavior 
was as above. 

4. Timing read error (TRE) flip-flop was set when 
a block mark occurred out of place or an ille- 
gitimate character was detected during a read 
octal operation. Certain timing errors in the 
DSU would also set this alarm. If NH was set, 
the converter would cease transmitting data 
and disconnect from the central processor. In 
the case of magnetic tape, it was instructed to 


search for an end of block mark and stop. NH 
behavior was as above. 

The Off-Line Control Unit 

Although it was a bit of an afterthought, an off- 
line control unit was invented by Humphrey and 
Terzian and proposed to the Signal Corps in an 
unsolicited proposal in 1959 (Humphrey and Ter- 
zian 1959). The device allowed the system to print 
or punch cards from magnetic tape without tying 
up the central computer. The Signal Corps ulti- 
mately ordered one of these units and it turned 
out to be a crucial piece of equipment in sup- 
porting the data processing load at Zweibrucken, 
Germany (Crawford 1985). 

Gazzola points out that this device was deliv- 
ered to Germany only half assembled and that Ray 
Greggor and Herb Brun, among others, spent the 
next several months completing the unit, shaking 
it down, and getting it into operation. Once it was 
functioning, however, it was extremely useful 
(Gazzola 1985). 


mobidic Circuits 


One of the first things Ed Cohler did when he 
arrived at Sylvania in 1956 was to initiate a se- 
ries of studies of alternate circuit design ap- 
proaches. The work was carried out by Greg Prom 
and produced the results shown in Table 6 (Coh- 
ler 1956). Comparisons were based on actual cir- 
cuit implementations of several standard logic 
circuits and circuit combinations. In the case of 
core-transistor logic, the numbers shown are for 
the low range of the estimates. The transistors 
for these circuits also required substantially higher 
performance than the other circuits, posing reli- 
ability questions. 

The approach selected for mobidic was all- 
transistor logic, using the microalloy 2N393 sur- 
face alloy transister, which was developed for the 
U.S. Air Force by MIT’s Lincoln Laboratory and 
manufactured by Sylvania. These components were 
selected because they maintained a high beta at 
collector currents of up to 50 ma. and were highly 
reliable. Even though the circuits did not nor- 
mally require such performance, this specifica- 
tion allowed for reliable performance when tran- 
sistor beta deteriorated by 50%, all circuit 
components and voltage values were out of spec- 
ification by 10% in the worst combination, and the 
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Table 6. mobidic Comparative Circuit Evaluation 


Number of Components 
Cores Diodes Transistors 


Speed 


Trans. /Diode 1 
Trans. /Diode 2 
Trans./Diode 3 
Transistor 
Core/Trans. 1 
Core/Trans. 2 


uabient temperatures varied between -30 to 

f65* C. s 

The basic mobidic circuits were the inverter, 
ti* emitter follower, the flip-flop, and the bus 
4 f 5 ver (Figures 11 to 14 respectively). The various 
gisuit combinations that were used to perform the 
je^jc functions are shown in Figure 15. 

The inverter circuit was capable of combining 
«» many as 20 different logical inputs, and its 
output could simultaneously drive one or two logic 
network inputs. 

The emitter-follower was used either to com- 
bine up to 10 inputs in OR networks or as a buffer 
driver for up to eight inverter loads. 

The flip-flop was designed to operate at one 
megacycle rates with full-state switching occur- 
ring within 0.25 microseconds. This circuit had 
it* own self-contained power amplifier, which could 
drive up to 10 logic networks. 


Much of the circuit data and all of the design diagrams 
•ere obtained from the Syivania proposal to the Signal Corps 
fcrthe Information Retrieval Unit, dated November 11, 1960. 



11. Inverter. 


Adequate 

Adequate 

Adequate 

Superior 

Marginal 

Marginal 


The bus drivers were used to drive the various 
system bus connections within mobidic. When 
several drivers were connected to a single bus line, 
they formed a logical OR circuit so that any sin- 
gle "one” would bring the entire bus line to the 
"one” state. 

In some cases, it was necessary to set or reset 
a large number of register stages simultaneously; 
the circuit that was used in this case was the reg- 
ister driver (Figure 16). 

The above circuits were combined into larger 
logic configurations, such as the register stages 
and control circuits shown in Figure 17. 


mobidic Memory Design 


mobidic used a standard magnetic ferrite core 
memory array with sense amplifiers and drive 
circuits. A total of 38 memory planes with 64 X- 
and 64 7-lines made up the 4,096-word 8-micro- 
second mobidic modular elements. Because of the 
stringent environmental conditions, these cir- 
cuits were designed to compensate for tempera- 
ture fluctuations and operate between -30 and 
+55° C ambient. This was accomplished by using 
temperature-sensitive ferrites to sense the am- 
bient temperature and, through a feedback am- 



Figure 12. Emitter follower. 
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ing of the strobe pulse with temperature. It wa* 
found that these features extended mobidic mem, 
ory operation 40° C below and 10° C above what 
could otherwise have been achieved. This range 
included the Signal Corps specifications (Ashley 
et al. undated). 


Circuit Reliability and Checking 

Several steps were taken to ensure mobidic ciiv 
cuit reliability. Transistors with inherently hi$ 
quality were first selected and then great care waj 
taken to minimize the number of active element^ 
required. While all-transistor logic used more 
transistors, it reduced the total number of circuit 
elements. Since the reliability of the available 
diodes was approximately the same as the tram 
sistors, this significantly improved overall relj. 
ability. 

Very conservative derating factors were also 
used (Sylvania undated). For example, the tran- 
sistors selected had been demonstrated to operate i' 
reliably in the mobidic class of circuits at rates 
of up to 10 megahertz, whereas mobidic only used 
a one-megahertz clock. The Sylvania 9400, which j 
was largely a repackaged version mobidic, ran at 
exactly twice mobidic’s speed with the identical f 
circuits and only minor adjustments in the mem- 
ory components to tune the strobe and drive cur- 
rents. Similar deratings were used for all other : 
circuit parameters. One caution was found nec- 
essary with deratings, however, since sufficient 
power dissipation was needed to minimize dam- 
age in high humidity conditions. Even though the 
components could operate or be stored in high-hu- 
midity environments, a minimal level of dissi- 
pative heating was found to improve reliability. 





Figure 14. Bus driver. 



plifier, to adjust the drive current, sense ampli- 
fier, and strobe timing (Cohler and Humphrey 
1959). 

The wide variation in ferrite core performance 
with temperature required several types of ad- 
justment. First, the drive currents were compen- 
sated to provide a constant core output signal be- 
low 10° C and a constant switching time at higher 
temperatures. A technique called "core-derived 
strobing” was also used to adjust the optimal tim- 
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In addition to the extensive checking already 
discussed, a unique marginal testing system was 
also implemented (Humphrey 1965). A coordinate 
arrangement of the marginal voltages powered the 
circuits and, by sequencing the voltage on these 
lines, the row and column containing a marginal 
package could be identified. By varying the X-lines 
and then the Y-Iines, the faulty circuit was found 
at the intersection of the marginal X- and Y-lines. 
If testing was performed reasonably frequently, 
only a single circuit would likely be mar ginal The 
circuit card at the X-Y intersection could then be 
replaced. 

The supplies used for marginal testing were the 
+4 volts for the inverters and -10 for the emitter 
followers. An increase in the +4 voltage detected 
a decrease in transistor beta, while a decrease 
checked for increased noise sensitivity. For the 
emitter followers, a lowering of the -10 supply 
checked for a reduced beta. 

mobidic turned out to be extremely reliable with 
mean time between failures in excess of 2,000 
hours when operated 24 hours a day, seven days 
a week. As a result, preventive maintenance was 


SECTION V fl 2 
RINGING 
CJRCUI T 

POINT b 



SECTION "B" 

i 

PREAMPLIFIER 

i 

02 


C4 

i 

i 

r H, ~! 

i 

b 


SECTION 0 
RH POWER INVERTER 


REGISTER R3 
| ORIVER 
i INPUT 




saB3hj 


k~4V C 5 


*OlNT 
a-v i 


GATE t/ 

INPUTo TQ9 


GATING ^ pie 
CIRCUIT < 6 


SECTION "C" 


OUTPUT CASCOOE 


OUTPUT*! I OUTPUT 2- 


SECTION "E“ 


RIO OUTPUT CASCOOE 


CIRCUIT LESS SECTION Va'C" « REGISTER ORIVER I f SECTION V 

CIRCUIT LESS SECTION "C" • PULSE DRIVER i 

SECTION "C" • GATE V 

* HE N GATE is NOT USED POINT a. MUST BE GROUNDED 

Figure 16. Register Driver or Gated Pulse Driver. 
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curtailed and then eliminated entirely without 
reduction in reliability or availability (Lipton et 
al. 1964). As a consequence, the extensive mar- 
ginal testing system turned out to be unneces- 
sary. 

In addition to the marginal testing provisions, 
a standard list of components was established, 
based on exhaustive testing, and only the com- 
ponents on this list could be used in the MOBIDIC 
circuit designs. Standard testing procedures were 
also defined for the component manufacturers, and 
Sylvania s receiving inspection department in- 
sured that all the components were within spec- 
ification. Finally, a standard set of basic circuits 
was established and packaged in small plug-in 
cards. These, together with a set of delay and 
loading rules, provided the only elements the 
MOBIDIC logic designers could use in the machine. 
These rules included a set of derating factors that 




To minimize army spare-parts stocking requs« 
ments, only a small number of standard circuit 
were used in 3mall replaceable packages (Figqy 
18). This also permitted the design of special cij 
cuit testers for use by military field maintenance 
personnel. To simplify testing, every flip-flop was 
also equippped with an indicator so the state o' 
the machine could be easily determined. 8 

The mobidic computer was designed to fit in , 
standard 30-foot army tractor-trailer van (Fig 
ures 19 to 21). The interior of the van was araph 
for the basic mobidic equipment, but there 
little space left for maintenance (Figure 22). 

The mobidic console also was designed to fit 
a compact environment (Figures 23 to 25). 9 T 
actual indicators and controls for the console i 
shown in Figures 26 and 27 (Sylvania 1960). 

mobidic was designed for extremely rugged 
physical environments. The equipment was to 
withstand vibration at 10 to 55 cps at 0.015-inch 
double amplitude. The shock specification 
15 g impulse of one-millisecond duration, an 
temperature range was from -65 to +125° F 
95% relative humidity, sand, and dust. \ 
mounted in the tractor trailer, it was requir 

’Figures 19-22 and the mobidic environmental specific! 
tions were obtained from the EJCC Special Edition of General 
Telephone and Electronics Corporation’s General News, dated 


Figure 18. mobidic circuit packaging. 


permitted the circuits to perform at the require 
speed while the environmental conditions varied 
and the components deteriorated toward their aij. 
ticipated end-of-life characteristics. 


mobidic Packaging 
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*he Belgian Block test and the Munson Road 
which simulated transport over extremely 
h terrain- 9 In fact, in the two runs of mobidic 
A berdeen Proving Ground Munson Road 
^ the army-supplied tractor-trailer vans were 
fn ‘ jjoth times, whereas the MOBIDIC com- 
- was undamaged (Lipton et al. 1964). 


ber 1957 between Mike Bosch, Watts Humphrey, 
and John Terzian of Sylvania and Dean Arden, a 
consultant from MIT. They were discussing ways 
to meet an anticipated Signal Corps’ need for 
smaller and more compact computing systems that. 
would be compatible with mobidic. During the 
discussion, it was suggested that some of the more 
complex mobidic instructions could be imple- 
mented with subroutines of the more basic in- 
structions. It was next suggested that some of the 
machine registers could be stored in memory, thus 
sharply reducing the circuitry required. In that 
one relatively brief afternoon meeting, many of 


frasi c machine organization of the mobidic b 
pyter was conceived at a meeting in Septem- 


mobidic with electrical connections. 


Figure 22. mobidic magnetic tape being serviced. 
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Figure 24. mobidic console. 


Figure 25. mobidic console — 7th Army installation. 
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taker the control register or the memory register 4. For a simple unindexed arithmetic operation, 
t* the desired action. the operand address was then in the lower 15 

for arithmetic operations, the machine per- bits of CR so it was read from memory into MR 

jotmed as follows: and rewritten. 

5. The operand was next moved to CR, and the 
J The instruction cycle started by reading the A register retrieved from memory. The arith- 

contents of the memory and moving it to CR. metic operation was then performed and the A 

The MR contents were then incremented by one register rewritten, 

and rewritten in memory, thus accomplishing 

Uie function of stepping the program counter. All of the operations of the mobidic b computer 

2. Since the next instruction address was then in were performed in this way through the use of 

the lower 15 bits of CR, it was read from mem- only two general-purpose registers. To save logic 

ory into MR and then rewritten. and system complexity, a number of the MOBIDIC 

^ Tms next instruction was then moved from MR instructions were actually implemented in sub- 

to CR and the 6-bit instruction code moved to routines of the more basic instructions. The MO- 

the decoder register. bidic b instruction set is shown in Table 7 (Chao 
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Figure 28. mobidic b processor. 

1959). Here, the full mobidic instruction list is 
shown together with several instructions labeled 
BSPL which were available as special MOBIDIC B 
instructions, to be implemented in subroutines. 
Fifteen of the mobidic instruction were subrou- 
tined, 9 were available for subroutines, and 40 
were directly implemented. The instruction tim- 
ings varied considerably depending on the char- 
acteristics of the instruction itself, the data being 
processed, and the operation of the other du- 
plexed mobidic b machine. 

The reason for this variation was that the two 
mobidic b computers shared a common bus for 
instruction and data transfers between memory 
and the I/O converters. To avoid any uncertainty, 
a system bus control circuit alternately assigned 
bus control to each processor every two microse- 
conds. A waiting period of two microseconds was 
therefore occasionally required by an instruction, 
depending on what it and the other processor were 
doing at that precise moment. 

The subroutined instructions were imple- 
mented in the following way: 

1. When such an operation code was encoun- 
tered, the contents of the accumulator and the 
program counter were automatically stored in 
their memory locations. 

2. The special address control circuitry directed 
memory access to a designated location, de- 
pending on the six-bit instruction operation 
code. 


3. Starting at this location, a program was 
cuted that performed the designated instruc- 
tion function. The program was implemented 
entirely in the directly implemented 40 basic 
mobidic instructions. 

4. At the conclusion of this subroutine program, 
the accumulator and program counter con- 
tents were restored and program execution 
continued as before. 

The mobidic special instructions designated a 
series of reserved locations which the program- 
mer could use as he or she chose. Locations were 
not designated in the machine architecture but a 
subroutine could be used for each one to augment 
the standard machine instruction set. 

mobidic b System Structure 

The overall structure of the mobidic b system is 
shown in Figure 29 (Chao 1959). The two proces- 
sors and their memories were connected to a com- 
mon system bus which in turn connected to the 
data retrieval unit, the two I/O converters, and 
the real-time units. Either mobidic B processor 
could access any I/O device through either con- 
verter and they both had equal access to the data 
retrieval unit (DRU). The I/O converters and de- 
vices performed in the same general way as in 
mobidic a with some special considerations caused 
by the possibility of interaction between the two 
processors. Each machine, for example, was ca- 
pable of executing I/O operations into or out of 
the memory of the other processor, and either could 
cause the other to be interrupted at any time. 
Further, either processor could initiate several 
I/O operations and occupy all the I/O, thus 
blocking the other unit. In the event of priority 
needs, it was possible for one processor to modify 
the contents of an I/O converter to shorten the 
other processors’ I/O operations. 

The real-time units were uniquely assigned to 
each mobidic b processor. That is, each processor 
could only access its designated RTU and this RTU 
could only access this processor’s memory. Through 
the RTlTs external connections, however, the pro- 
cessors could communicate with each other or with 
other Fieldata equipment. 

The mobidic b Data Retrieval Unit 

The DRU was designed to assist in the search 
process and it permitted either machine to ini- 
tiate a search of the mass memory or magnetic 
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Table 7. mobidic b Instruction Summary 


Octal 

Code 

Operation 

Abbrev. 

Operation 

Instruction 

T ype a 

Timing 

00 

HLT 

Halt 

D 

24 

01 

RPT 

Repeat 

R 

— 

02 

LGM 

Logical Multiply 

D 

38 

03 

LGA 

Logical Add 

D 

38 

04 

LGN 

Logical Negation 

D 

36 

05 

SEN 

Sense 

D 

28 

06 

SNS 

Sense and Set 

D 

28 

07 

SNR 

Sense and Reset 

D 

28 

10 

CIA 

Clear and Add 

D 

36 

11 

CAM 

Clear and Add Magnitude 

D 

36 

12 

ADD 

Add 

D 

44 

13 

ADM 

Add Magnitude 

D 

44 

14 

CLS 

Clear and Subtract 

D 

36 

15 

CSM 

Clear and Sub. Magnitude 

D 

36 

16 

SUB 

Subtract 

D 

44 

17 

SBM 

Subtract Magnitude 

D 

44 

20 

MLY 

Multiply 

D 

88-774 

21 

MLR 

Multiply and Round 

D 

88-786 

22 

DVD 

Divide 

R 



23 

DVL 

Divide Long 

R 



24 

ADB 

Add Beta 

R 



25 

SBB 

Subtract Beta 

R 



26 

BSPL 

mobidic b Special 

S 



27 

BSPL 

mobidic b Special 

S 

— 

30 

SHL 

Shift Left 

D 

30-66 

31 

SLL 

Shift Left Long 

D 

46-118 

32 

SHR 

Shift Right 

D 

30-66 

33 

SRL 

Shift Right Long 

R 

— 

34 

CYS 

Cycle Short 

D 

30-66 

35 

CYL 

Cycle Long 

R 

— 

36 

SLA 

Shift Left & Log. Add 

D 

30-66 

37 

NRM 

Normalize 

R 



40 

TRU 

Uncond. Transfer 

D 

28 

41 

TRL 

Load PCS and Transfer 

R 



42 

TRS 

Transfer to PCS 

R 



43 

TRX 

Transfer on Index 

R 



44 

TRP 

Transfer on Positive A 

D 

26 

45 

TRZ 

Transfer on Zero A 

D 

26 

46 

TRN 

Transfer on Negative A 

D 

26 

47 

TRC 

Compare 

R 

— 

50 

STR 

Store 

D 

34 

51 

LOD 

Load 

D 

36 

52 

MOV 

Move 

D 

36 

53 

LDX 

Load index 

R 



54 

RPA 

Replace Address 

R 

— 

55 

MSK 

Replace through Mask 

R 

— 

56 

BSPL 

mobidic b Special 

S 

— 

57 

TRY 

Transfer on Index B 

D 

38 

60 

BSPL 

mobidic b Special 

S 

— 

61 

BSPL 

mobidic b Special 

S 

— 

62 

BSPL 

mobidic b Special 

S 

— 

63 

BSPL 

mobidic b Special 

S 

— 

64 

BSPL 

mobidic 8 Special 

S 

— 

65 

BSPL 

mobidic b Special 

S 

— 

66 

SKP 

Skip 

D 

30 

67 

BSP 

Back Space 

D 

30 

70 

RAN 

Read Alphanumeric 

D 

30 

71 

RRV 

Read Reverse 

D 

30 

72 

ROK 

Read Octal 

D 

30 

73 

SCH 

Search 

D 

30 

74 

WAN 

Write Alphanumeric 

D 

30 

75 

WWA 

Rewrite Alphanumeric 

D 

30 

76 

WOK 

Write Octal 

D 

30 

77 

RWD 

Rewind 

D 

30 







'D — directly implemented instruction, R — subroutined instruction, S — mobidic b special instruction. 
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Figure 29. mobidic B system block diagram. 
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tapes. The search parameters were provided by 
the processor to the DRU and then it would pro- 
ceed without placing further demands on the pro- 
cessor. When the search was completed, the de- 
sired portions of the files being searched were sent 
to the initiating processor’s designated memory 
locations and the DRU was then freed for further 
searching. 

Although the data retrieval unit had an excit- 
ing potential for file management and retrieval 
applications, the author has been unable to find 
a comprehensive description of the device. 

mobidic b Input-Output Devices 

The mobidic B mass memory consisted of 8 two- 
sided 34^ inch diameter magnetic disks with a to- 
tal of 4,096 tracks on each surface. Data were 
stored serial-serial with clock rates of 150 and 225 
kc, and a maximum random access time of 0.25 
seconds. Two of these units were actually built, 
delivered, and used with MOBIDIC B, but they were 
far too bulky for general use and no more units 
were manufactured (Cohler 1985; Lipton et al. 
1964). 

mobidic B also had eight magnetic tapes, a 10 
cps Flexowriter printer, and both 5- and 8-hole 
paper tape readers and punches (Chao 1959). 

mobidic b Duplexing 

MOBIDIC B had sophisticated capabilities for com- 
munication between the two processors. For ex- 
ample, a set of control lines permitted each pro- 


cessor to monitor the performance of the other. 
One could then prevent the other from halting and 
hold it in a ready state to accept information 
transferred to it. Further, either processor could 
restart the other after it had completed a pro- 
gram, or one could give an I/O instruction to be 
executed by the other. If one processor gave a write 
instruction to have information from the other’s 
memory written on magnetic tape, it could then 
read the information from this tape into its own 
memory. This ability allowed either processor to 
access data produced by the other, or one proces- 
sor could cause its own memory contents to be 
placed in the memory of the other (Chao 1959). 

The MOBIDIC B control consoles were also du- 
plexed and placed side by side so one operator could 
run both machines simultaneously. These con- 
soles contained much the same functions as the 
mobidic console previously discussed, including 
marginal testing controls, master clock controls, 
and display registers. Each computer also had its 
own controls for such manual operations as stop, 
power-on, start, and single pulse. 

Conclusions 

The mobidic and Fieidata programs were leaders 
in the computing field in several important ways. 
They spawned the design and production of a few 
fine machines; some of the early operating ex- 
periences foreshadowed the subsequent 25 to 30 
years of computer practice; and many of the ad- 
vanced design concepts were implemented years 
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j. J L . ^ e ir appearance in the computer industry 


yktsie the mobidic systems were operating in their 
^ j n Germany they experienced few outages, 
v fict. Ray Gazzola remarks that he cannot re- 
a single instance where the 7th Army’s 
control operation was impacted by machine 
disability- They did have power failures, of 
00 X 96 , and the magnetic tape units were a pe- 
^raial problem. Gazzola even recalls a special 
^ a r d of operating in tractor-trailer vans. Oc- 
casionally, another large tractor-trailer would pull 
yp beside the mobidic units and the electrical in- 
difference would cause multiple errors in mob- 
g>K’’s sensitive circuits (Gazzola 1985). 

the best indicator of the reliability of these 
Interns, however, is actual operating data. Table 
I gives the transistor counts for mobidic’s 7 a and 
p which were installed in the 7th Army’s stock 
control center in Germany in 1963. These ma- 
chines had a total of some 57,000 transistors in 
{feeir combined central processing units plus an- 
other 7,000 in the off-line control unit. The avail- 
ability of each of the central computer complexes 
was better than 99.7% (Table 9). In fact, for the 
on tire operating period of MOBIDIC D, no central 


Table 8. mobidic Transistor Count 


Transistor Count 

MOBIDIC 7A 

MOBIDIC D 

Total 

CPU 

13,754 

13,754 

27,508 

I/O Converters 

10,496 

10,496 

20,992 

Memories 

3,054 

6,108 

9,162 

OCLU 


7,065 

7,065 

Total 

27,304 

37,423 

64,727 


Table 9. mobidic Reliability 



MOBIDIC 7A 

MOBIDIC D 

Hours of Operation 

23,412 

6,352 

Mean Time Between Failures: 


OP System 

1,801 

2,117 

CPU Only 

5,853 

No fails 

I/O Converters Only 

No fails 

No fails 

4,09b Word Memories 



Only 

6.690 

12,704 

Off-Line Control Unit 



_ 0n| y 


3,283 

/flai Availability 

.999 

.9976 


processor failure was recorded and none of the in- 
put/output converters experienced failure in 60,000 
hours of operation (each machine had two con- 
verters) (Lipton et al. 1964). 

As good as these figures are, the machines’ 
performance was still improving at the time these 
data were taken. Clearly, the operating experi- 
ence with the mobidic machines of 20 years ago 
attests to the value of a conservative design phi- 
losophy and painstaking attention to manufac- 
turing quality. 

Operation 

The experiences of the programming and opera- 
tions groups in Germany were also a clear indi- 
cation of the advanced nature of the challenges 
they faced. The first operational mobidic instal- 
lation, mobidic 7A, occurred in Germany in March 
1961. At that time there was no mobidic cobol 
so the entire application had to be written in as- 
sembly language. Because there was also no op- 
erating facility available, the group had to pro- 
duce its owm operator control system as well as 
many other support programs. 

The application for this machine was the man- 
agement of repair parts for the entire U.S. 7th 
Army in Europe, which included the Chemical, 
Signal, Medical, Engineering, Quartermaster, and 
Transportation technical services and involved 
direct control over the distribution and ordering 
of parts for every army stock center in Europe. 
The application was huge and involved a pre-au- 
dit run, a sort merge, cross-reference, another sort, 
a balance run to update the stock records of every 
center, and final file maintenance and report runs. 
The entire application was run three times a week 
and generally took more than 24 hours; the bal- 
ance runs alone took six to seven hours. In ad- 
dition, there were monthly and quarterly runs 
which took even longer. 

The application programs were initially devel- 
oped in the U.S., but the army changed the stock 
control system from MASS to MILSTRIP right in 
the middle of this period, so the entire application 
had to be completely reworked by the group in 
Germany. To do this, the army sent 25 to 30 en- 
listees to school, selected on the basis of aptitude 
tests. The group was to work for the two years 
until their enlistments ran out and then they 
would all be replaced. 

As Gazzola points out, this was the first ex- 
ample he knows where good development and test 
practices were used. They knew that all the de- 
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velopers would leave at the same time and an en- 
tirely new crew of raw recruits would have to tak p 
over. In fact, as Gazzola tells it, this actually hap- 
pened and both teams did such a remarkable job 
that the system continued to function right through 
the transition. This was probably the first ex- 
ample of the use of modem documentation and 
project control practices that are now common in 
complex data processing installations (Gazzola 
1985). 


Advanced Concepts 

Fieldata was the first program to demonstrate the 
implementation of a compatible architecture by 
multiple manufacturers across widely varying 
machine types. Though this was in fact accom- 
plished, there were some mistakes, particularly 
concerning the allowance of undefined instruc- 
tions and the handling of anomolous instruction 
results. One clear lesson from this program was 
the need for rigorous and detailed architectural 
- control over all facets of system design. If every 
externally detectable aspect of the system’s ar- 
chitecture is not controlled, full compatibility 
cannot be achieved. 

mobidic B was also either the first or nearly 
the first to use a concept analogous to micropro- 
gramming and to implement virtual registers. 
Although all the implications were not recognized 
at the time, the idea of separating the machine’s 
data flow from its architecture was clearly rec- 
ognized and implemented, mobidic b also imple- 
mented most of the functions of polymorphic mul- 
tiprocessing systems many years before their 
commercial introduction. Because there is no rec- 
ord of these capabilities of the mobidic machines 
actually being used in operation, the experience 
was probably of little long-term consequence. 

The Bryant disk files were also a first of their 
kind. True, they were enormous units, but their 
installation and use in an operating enviro nm ent 
in 1961 was clearly an advance, though few peo- 
ple were aware of it at the time (Lipton et al. 1964). 

The Fieldata interconnection standard was also 
a precursor to such modern facilities as RS232. 
Fieldata used 21 lines and transmitted a char- 
acter at a time; RS232 uses 25 lines and trans- 
mits in serial-serial. The experiences of the Sig- 
nal Corps in this regard, however, were clearly a 
foretaste of all that was to follow. According to 
Luebbert, it was always troublesome getting the 
hardware engineers at the working level to ac- 
cept the added cost of general-purpose interfaces. 


They could never see the value of the interface, 
and always fought their use (Luebbert 1985). Some 
things apparently never change. 

The Fieldata code aiso broke new ground. Be 
cause of his work on this code, Luebbert was ip. 
vited to participate in the initial discussions to 
establish the ASCII code. As Luebbert describes 
it (Luebbert 1985), the first question they ad- 
dressed was whether the Fieldata code should be 
adopted. Luebbert opposed this proposal because 
he felt that the compromises made in Fieldata to 
accommodate teletype were uniquely applicable 
to the Signal Corps and would in the long run be 
detrimental to more general-purpose codes. One 
of Luebbert’s main concerns was that the Fieldata 
code, though it was collatable, did not have a sim- 
ple alphabetic/numeric relationship. Many other 
members of the ASCII committee also felt that 
the letters of the alphabet should be associated 
with the 4-bit binary code characters from 1 to 26 
The Fieldata code’s use of the initial six teletype 
control characters in both upper and lower case 
meant that it could not meet this objective. It was 
thus ruled out as a candidate and the ASCII com- 
mittee went on to consider other alternatives. 

The People 

Probably the most lasting and certainly reward- 
ing part of the mobidic and Fieldata programs 
concerned the people. The Sylvania development 
team was new and inexperienced but did a re- 
markable job. The same was certainly true of the 
mobidic team which Al Fullerton headed in Ger- 
many. As Gazzola said, "Looking back, the group 
had high morale and esprit de corps. It was one 
of the best professional teams I have ever known” 
(Gazzola 1985). Silverstein referred to this period 
as the "golden era” of the Signal Corps. He said, 
The critical factor for rapid progress was the 
young officers they educated and trained and gave 
responsibilities way behind their rank and ex- 
perience. His closing comment perhaps speaks 
for everyone involved when he said that his par- 
ticipation in writing this history has "rekindled 
warm memories of the best period of my life.” 10 
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Appendix A: The Fieldata Code 

The basic criteria that the Signal Corps estab- 
lished for the Fieldata code were printed in the 
first Fieldata Development Report which was 
published in March 1958 (USASRDL undated, 
USASRDL 1959). 

1. The code should be a true alphanumeric code; 
that is, the meaning of a given character should 
not depend on previous characters. 

2. There should be the simplest possible logical 
tests to distinguish symbols, numbers, letters, 
and control functions from one another. 

3. The numeric portion of the code should be bi- 
nary coded. 

4. The alphabetic portion should have a simple 
weighted relationship with code position. 

5. The code should have maximum compatibility 
with existing widely used data processing and 
data transmission codes (i.e., teletype). 

6. It should be nonredundant and capable of op- 


tional error detection or error correction when 
needed. 


After some study, it was concluded that none 
of the existing codes would be entirely suitable so 
a new 8-bit code was selected. The 8-bit positions 
were assigned in the following way (USASRDL 
1959): 

D 0 First data bit 
Dj Second data bit 
D 2 Third data bit 
D 3 Fourth data bit 

11 First indicator bit 

1 2 Second indicator bit 

C Control bit 

P Odd parity bit 

The actual arrangement of the rightmost 6 bits 
of the Fieldata code is shown in Table 10. This is 
the 64 binary combinations of the low-order 6 bits 
with a "1” in the 7th or control position. With this 
code arrangement, a binary sort produced both a 
numeric and an alphabetic sort, with the letters 
before the numbers. Similarly, the 10 bit distin- 
guished between alphabetic and numeric char- 
acters. 

The 64 control characters are shown in Table 
11. The following notes from the Signal Corps 
publication, "Fieldata Equipment Intercommuni- 
cation Characteristics,” of April 1, 1959 explain 
this table (USASRDL 1959): 


a. The alphanumeric characters in the first two 
columns (Master Space through Z) are used 


Table 10 . Fieldata Alphanumeric Code 


D 3 D 2 Di Do 

Mi 

00 

Mi 

01 

I 2 I 1 

10 

y, 

ii 

0000 

Master Space 

K 

) 

0 

0001 

Upper Case 

L 


i 

0010 

Lower Case 

M 

+ 

2 

0011 

Tab. 

N 

< 

3 

0100 

Car. Ret. 

O 


4 

0101 

Space 

P 

> 

5 

0110 

A 

Q 


6 

0111 

8 

R 

$ 

7 

1000 

C 

S 

* 

8 

1001 

D 

T 

( 

9 

1010 

E 

U 



1011 

F 

V 



1100 

G 

w 

7 

/ 

1101 

H 

X 

! 


1110 

1 

V 

, 

Soecial 

1111 

J 

z 

0 

Backspace 
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11. Fieldata Control Function Code 


ment of the MOBIDIC machines as well as for com- 
munication between Fieldata devices. 


Appendix B: The mobidic instructions 


(Master Space) (K) Blank RTT 

(Upper Case) (L) Dial 1 RTR 

(Lower Case) (M) Dial 2 NRR 

(Tab,) (N) Dial 3 EOBK 

(Car. Ret.) (O) Dial 4 EOB 

(Space) (P) Dial 5 EOF 

(A) (Q) Dial 6 ILL 

(B) (R) Dial 7 AKR 

(C) (S) Dial 8 RPB 

(D) (T) Dial 9 SPARE 

(E) (U) Dial 0 SPARE 

(F) (V) SOB SPARE 

(G) (W) SOD SPARE 

(H) (X) TST SPARE 

(I) (Y) TCL SPC 

(J) (Z) STOP DELETE 


In the following description of representative 
mobidic instructions, the format and notation used 
are from the MOBIDIC Programming Manual of 
April 1960 (Sylvania 1960): 


1. Unless noted, each instruction could be in- 
dexed. 

2. All numeric data words and order words are 
given in octal. 

3. The symbol C( ) is used to indicate the con- 
tents of the location given in parentheses. That 
is, C(A ) refers to the contents of the accumu- 
lator or A register. 

4. A subscript indicates the bit position; that is 
C(141) 17 indicates bit position 17 of memory 
address 141, and A 10 refers to bit position 10 
of the A register. 

5. Normally, the operation codes are written with 
their gamma, beta, and alpha addresses noted. 
An instruction written CLAya indicates that 
the beta bits of the instruction have no func- 
tion. 


for supervisory chatting over communication 
lines and are not to be transmitted beyond one 
communication link. 

b Blank is an idle condition used with data ter- 
minal equipment. It is transmitted but the re- 
ceiver, on this character, does not emit a strobe 
signal. 

c Dial 1 through Dial 0 are used to initiate tele- 
phone dial tones for automatic switching sys- 
tems. 

4 . SOB — Start of block 
*. SOD — Start of data 
i TST — Tab set 
f, TCL — Tab clear 
jk RTT — Ready to transmit 
L RTR — Ready to receive 
y NRR — Not ready to receive 

k. EOBK — End of blockette (a 24-character block) 

l, EOB — End of block (length undefined) 

». EOF — End of file 

ft. ILL — Ignore — illegitimate noncorrectable 
character 

o AKR — Acknowledge receipt 
p. RPB — Repeat last blockette or last block 
$ SPC — Special control (followed by a binary 
number for remote address) 
f- DELETE is the all ones combination (111111) 
and it was used as a code delete for papier tape. 
*■ The only control functions for computer use 
were Blank, SOB, SOD, TST, TCL, STOP, 
EOBK, EOF, RPB, DELETE 

This code was adopted for use in the I/O equip- 


In understanding these instructions, the inter- 
nal machine addresses are occasionally used so 
their values are important. Table 12 gives the 
mobidic registers and their octal memory ad- 
dresses and Table 13 gives the mobidic sense flip- 
flops and their octal addresses. In the instruction 
descriptions, the instruction name is first given, 
followed by its octal designation, its three-letter 
mnemonic, the instruction and address fields used, 
and the instruction execution time in microse- 
conds. 


Internal Data Handling Instructions 

These instructions were used for moving infor- 
mation within the machine: 


LOAD, 51, LOD-ypa, 18 psec. 

C(p): = C(a + C(y)) 

The contents of register beta as set to the 
value at the address given by adding alpha 
to the contents of index register gamma. If 
a register was addressed, gamma must have 
been 0. 
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Table 12. mobidic Register Addresses 


Octal 

Addresses 

Register Name 

Abbreviation 

00000-07777 

Memory Unit Zero 


60000-67777 

Memory Unit Six 


70001 

Index Register One 

11 

70002 

Index Register Two 

12 

70003 

Index Register Three 

13 

70004 

Index Register Four 

14 

7001 0 

Accumulator 

A 

70011 

Q Register 

Q 

70012 

B Register 

B 

70013 

Program Counter 

PC 

70014 

Program Counter Store 

PCS 

7001 5 a 

Converter Instruction 
Register 

CRI 

70020 

Word Switch Register 

WSR 

70021 

Real-Time Address 
Register 

RAR 

70022 

Real-Time Output 
Register 

ROR 

70030 

Instruction Register of 

CIS1 


First I/O Converter 


7003N 

Instruction Register of 

Nth I/O Converter 

OSIN 


“When this address was used with an I/O instruction, the 
selected converter stored the contents of its buffer register in its 
instruction word register. 


The other instructions in this general category 
perform similar functions as follows: 

STORE, 50, STRya, 18 psec. 

CLEAR AND ADD, 10, CLAya, 16 (xsec. 
REPLACE ADDRESS, 54, RPAya. 22 jjtsec 
REPLACE THROUGH MASK, 55, MSKya, 22 

(j.3ec. 

The bits of C(a) which corresponded to "r’s 
in C(Q) were replaced by the corresponding 
bits in C(A). The remainder of C(a) was un- 
changed. 

MOVE, 52, MOVyBa, 26 |xsec. 

C(yP): = C(a) 

The 15 bits yP were used to form a full ad- 
dress, and indexing could not be used. As de- 
scribed later, when this instruction was used 
with the repeat instruction, large blocks of 
data could be readily moved. 

Arithmetic Instructions 

The arithmetic instructions behaved as follows: 

ADD, 12, ADDy/Sa, 16 fisec. 

SUBTRACT, 16, SUB-y/Sa, 16 /nsec. 

ADD MAGNITUDE, 13, ADMyjSa, 16 /isec. 
SUBTRACT MAGNITUDE, 17, SBMyjSa, 16 



V-C'vVf 


Table 13. mobidic Sense Flip-Flops 


Octal 

Address 

Abbrev. 

Function 

Set 

Program 

Clear 

Console 

Switch 

0001 a 

IOD 

In-Out Busy Signals 

No 

No 

' 

No 

. 

0077 a 

IOD 

In-Out Busy Signals 

No 

No 

V 

No 

0100 

OA 

Overflow Alarm 

No 4 

Yes 

Yes 

0101 

ROPI 

Real-Time Output Program 
Interrupt 

No 

Yes 

Yes 

0102 

ISN 

Interpret Sign 

Yes 

Yes 

Yes 

0103 

NHC 

Ignore In-Out Converter Error 

Yes 

Yes 

Yes 

0104 

RPE 

Real-Time Parity Error 

No 

Yes 

No 

0105 

ROBB 

Real-Time Output Busy 

No 

No 

No 

0106 

HOHag 

Real-Time Out. Reg. Bit 38 

No 

Yes 

Yes 

0110 

SFF, 

General Sense Flip-Flop 1 

Yes 

Yes 

Yes 

0127 

sff 16 

General Sense Flip-Flop 16 

Yes 

Yes 

Yes 

0130 

IOA1 

In-Out Alarm Converter 1 

No® 

Yes 

No 

0131 

IOA2 

In-Out Alarm Converter 2 

No® 

Yes 

No 

0135 

TPE 

Tape Erase 

Yes 

Yes 

Yes 

— 

TRA 

Trapping Mode 

Yes 

Yes® 

Yes® 


“These addresses corresponded to the address of the device being sensed. They were levels not flip-flops. 
“Could be reset by CLEAR ERROR button. 

“Done only by b bits of TRU order or when an order was trapped. 
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clE AR AND SUBTRACT, 14, CLSya, 16 fisec. 
CLEAR AND ADD MAGNITUDE, 11, CAMya, 
16 fisec. 

CLEAR and SUBTRACT MAGNITUDE, 15, 
CSMya, 16 fisec. 

These instructions all replaced the contents 
of register A with the designated sum or dif- 
ference of A with register or memory address 
a 4- C(y). Register B was left with a value 
that depended on the relative signs and mag- 
nitudes of the numbers involved. 
MULTIPLY, 20, MLYya, 86 fisec. 

MULTIPLY AND ROUND, 21, MLRya, 86 jusec. 
The 72-bit product was left in the A and Q 
registers, with A holding the high-order bits. 
Both signs were set and, for MLR, rounding 
was done by adding or subtracting 1 from the 
lowest order bit of Q depending on whether 
the result was positive or negative. 

DIVIDE, 22, DVDyjSa, 88 fisec (18 fisec if over- 
flow) 

DIVIDE LONG, 23, DVLy/3a, 88 fisec (18 fisec 
if overflow) 

In divide, the 36-bit value of C(A) divided by 
C(a ) was left in the Q register with the re- 
mainder in A. For long divide, the high order 
36 bits of the result were left in A and the 
low 36 bits in Q. 

NORMALIZE, 37, NRMya, 18 + n — ft (mod 2) 
fisec., ft = number of shifts. The contents of 
A as shifted left until the first 1 appeared in 
A 36 . The sign bit was left unchanged. 

SHIFT RIGHT, 32, SHRya, a > 14: 2 + a + 
a(mod2) fisec ; else 16 fisec. 

SHIFT RIGHT LONG, 33, SRLya, a > 14: 2 + 
a + a(mod2) fisec; else 16 fisec. 

SHIFT LEFT, 30, SHLy/3a, a > 9: 8 + a - 
ar(mod2) fisec; else 16 fisec. 

SHIFT LEFT LONG, 31, SLLy/3n, a > 9: 8 + 
a — a(mod2) fisec; else 16 fisec. These in- 
structions shifted the A or A and Q registers 
left or right a(modl28) places. 

The addition, subtraction, and division instruc- 
tions could cause overflow in the normal manner 
*s could the shift instructions when a nonzero bit 
was shifted out of A 36 . In the event of overflow, 
Table 14 shows how the three low-order bits of 3 
controlled the setting of the overflow alarm (OA) 
Hip-flop and the subsequent behavior of the ma- 
chine. The OA flip-flop could be sensed, set, and 
r f set under program control and could also be 
cleared from the console by pushing the RESET 
ERROR button. 


Table 14 . mobidic Overflow Behavior 


Action Before 
Execution 


Action After 
Execution 


Clear OA 
Clear OA 
Clear OA 
Clear OA 
No Action 
No Action 
No Action 
No Action 


Set OA and Halt 
Set OA 

Set OA and Halt 
No Action 
Set OA and Halt 
Set OA 

Set OA and Halt 
No Action 


Editing Instructions 

These instructions were used for internal data 
formatting: 

CYCLE SHORT, 34, CYSya, a > 14: 2 4- a + 
a(mod2) fisec; else 16 fisec. 

CYCLE LONG, 35, CYLya, a > 14: 2 4- a 4- 
a(mod2) fisec; else 16 fisec. These cycled the 
A or A and Q registers a(modl28) places to 
the left and left the sign bits unchanged. 

LOGICAL ADD, 03, LGAya, 16 fisec. 

LOGICAL MULTIPLY, 02, LGMya, 16 fisec. 

LOGICAL NEGATION, 04, LGNya, 16 fisec. 
These instructions performed the indicated 
Boolean operations on C(A) or on C(A) and 
C(a + C(y)) and left the result in A. 


Sequencing Instructions 

The transfer instructions in mobidic could only 
transfer to a memory address. If an instruction 
attempted to transfer to a register or some other 
location, the machine would halt. 

UNCONDITIONAL TRANSFER, 40, TRUy/3a, 
16 fisec. 

TRANSFER ON NEGATIVE ACCUMULA- 
TOR, 46, TRNya, 16 fisec. 

TRANSFER ON POSITIVE ACCUMULA- 

. TOR, 44, TRPya, 16 fisec. 

TRANSFER ON ZERO ACCUMULATOR, 45, 
TRZya, 16 fisec. 

HALT, 00, HLT, 16 fisec. 

These all performed the indicated operations 
and, except for HALT, they could be indexed 

COMPARE, 47, TRCya, 22 fisec. 

C(B), C(Q): = a, C(A) and if C(A) < C(a ): in- 
struction sequence continued; if C(A) > C(a): 
the next instruction was skipped; if C(A) = 
C(a): the next two instructions were skipped. 
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SENSE, 05, SEN-yft*, 16 m sec. 

SENSE AND SET, 06, SNSy/3a, 16 fxsec. 
SENSE AND RESET, 07 SNRyft*, 16 ^sec. 
The flip-flop specified by p was sensed and 
either set or reset as appropriate. In SEN and 
SNR, control was transferred to address a 
when the original state of this flip-flop was 
set and, in SNS, control was transferred if it 
started out reset. 

Indexing Instructions 

Though the MOBIDIC architecture permitted seven 
index registers, the actual machines built only 
contained four. The arithmetic operations on the 
index register addresses were designed so that the 
result was always modulo the number of registers 
in the machine. If the y bits in an instruction were 
either 0 or greater than the number of index reg- 
isters, however, no index register was used in the 
instruction. Further, if data from a nonexistent 
index register were called for by any instruction, 
the number 0 was used. 

LOAD INDEX, 53, LDX-yft*, 16 nsec. 

C(Iy), C(Iy + 1) =: ft a 

The LDX instruction always modified two 

index registers 

TRANSFER ON INDEX, 43, TRXypa, 22 Msec. 
Two index registers were used in this in- 
struction: y was decremented by one and 
sensed, and y + 1 was incremented by ft 
When y reached 0, control continued in order 
but when y was nonzero, control was trans- 
ferred to a. 

ADD BETA, 24, ADB yfia, 26 ^sec. 

A, Cta), C(Q), I{y) =: C(a) + ft C(a) + ft C(A), 
Cta) + ft p was added to the lower 12 bits 
of Cta) and overflow was ignored. 
SUBTRACT BETA, 25, SBByftr, 26 Msec. 

The same as above, with subtraction. 

LOAD PCS AND TRANSFER, 41, TRL-yft* 16 
Msec. 

The address of the next instruction in se- 
quence was stored in PCS. 

TRANSFER TO PCS, 42, TRS, 16 Msec. 

Control was transferred to the instruction 
address in PCS. 

REPEAT, 01, RPT-yft*, 16 Msec. 

If the next instruction was not an I/O op- 
eration it was repeated a total of a + Cty) + 

1 times. With each cycle, the contents of in- 
dex register gamma as incremented by beta. 
Index registers 3 and 4 were left with con- 
tents zero and beta, respectively. 


The repeat instruction, when used in coiyune* 
tion with the move or compare instructions, 
vided powerful capabilities. For example, the Rg, 
PEAT-MOVE sequence moved a block of words 
from one set of consecutive memory locations to 
another. The source locations for a move could als© 
be spaced at regular intervals, such as every iGth 
word. Another possibility was to move from con. 
secutive locations to every nth location, which 
would serve to spread out a block. Finally, a group 
of words could be taken from every nth location 
in one block and moved to every with location in 
another. 

The REPEAT-COMPARE sequence permitted 
the programmer to search through a list to find 
the value that equaled a given argument. The list 
might be contiguous or not and the search would 
be continued until a match was made, the search 
argument was exceeded, or the specified number 
of repeat cycles had been completed. At the end 
of this cycle, the original contents of the accu- 
mulator were left unchanged and the latest value 
used for comparison was left in the B register. The 
operation of this sequence of instructions is shown 
in Figure 30. 

Input-Output Instructions 

When MOBIDIC gave an I/O instruction, the sta- 
tus of all the converters and the identified device 
was sensed. If the device was busy or no converter 
was free, computer operation was suspended until 
the required units were available and then pro- 
cessing continued. If the sign of the word being 
transferred was to be interpreted, the interpret \ 
sign flip-flop had to be set by a SENSE AND SET 
instruction prior to I/O instruction execution. This 
ISN flip-flop was automatically reset when the 
I/O instruction was passed to the selected con- 
verter. 


In the following instruction descriptions, tim- 
ing information is omitted because every I/O in- 
struction took 16 microseconds plus device time 



Figure 30. Operation of the REPEAT-COMPARE se- 


quence. 
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g microseconds for each word transferred to 
mobidic memory. 

WRITE ALPHANUMERIC, 74, WAN kja 
This instruction wrote k words on output de- 
vice y starting at MOBIDIC memory location 
a . If the ISN flip-flop had not been set, the 
sign was ignored and each word was written 
as six 6-bit characters. When ISN had been 
set, a 6-bit sign character was first recorded 
followed by the rest of the word, high-order 
characters first. 

For magnetic tape devices, special block marks 
vtre automatically recorded before the first word 
and after the k word. An interblock gap was also 
hft between each terminating block mark and the 
beginning block mark of the next block. After a 
WAN order was given, this gap introduced a de- 
biy of approximately 6.2 milliseconds before the 
first word was transmitted from memory. It took 
about 11 milliseconds for the tape to pass over the 
complete interrecord gap and words were there- 
after recorded at 144 or 168 microseconds per word, 
depending on the status of ISN. 

When this instruction was used for other de- 
vices, such as the Flexowriter, special control 
symbols were used to control device operation. 

WRITE OCTAL, 76, WOK kja 
This instruction was similar to WAN but it 
permitted mobidic to record binary words on 
devices that handled 6-bit characters. Each 
mobidic word was split into 12 octal digits 
plus sign and each octal character was con- 
verted to 6-bit form in the converter 
READ OCTAL, 72, ROKjfeya 
This instruction allowed mobidic to read bi- 
nary words from paper tape. Again, it read 
k words from device y and placed them in 
memory starting at address. Each word was 
13 characters, starting with sign and the high- 
order bits. Any nonoctal characters were ig- 
nored by the converter and reading pro- 
ceeded until k words had been transmitted or 
a stop code was encountered. 

READ ALPHANUMERIC, 70, RAN kja 
READ REVERSE, 71, RRVkja 
For magnetic tape, these instructions read k 
words or blocks forward or backward, mod- 
ulo 256, into the memory addresses starting 
at a. When the ninth bit of k was one, the 
remaining 8 bits of k determined the number 
of blocks to be read. When k 9 was 0, k counted 
the number of words to be read. 


In reading from paper tape, the mode of oper- 
ation depended on the ISN flip-flop. When it was 
set, each word included a sign character and was 
read as sign plus six 6-bit characters. Reading 
continued until the 9-bit k count was completed 
or a stop code was encountered. Any unfilled 
character positions in a word were then filled with 
zeros. 

When the ISN bit was not set, two modes were 
possible, depending on bit 9 of k. When it was 1, 
six characters were grouped to form a word which 
was stored in memory. When it was 0, each char- 
acter was stored as the low-order 6 bits of a full 
MOBIDIC word and the rest of the word was filled 
with zeros. In these cases, k counted only modulo 
256 and the stop code was read as the last char- 
acter and placed in the last mobidic word stored. 

SKIP, 66, SKP kj 
BACKSPACE, 67, BSP/fey 
Magnetic tape unit y skipped k blocks for- 
ward or backward. 

REWIND, 77, RWDy 

Magnetic tape unity was rewound. After the 
instruction was initiated, the device contin- 
ued under DSU control and the converter was 
disconnected and available. 

REWRITE ALPHANUMERIC, 75, WWAkja 
This order started tape unit j reading for- 
ward until it encountered a beginning block 
mark. When found, it then switched to the 
record mode and wrote 6(mod 256) words from 
mobidic memory addresses starting at a. 
When no block mark was found, the entire 
tape was searched. 

Appendix C: I/O Converter Operation 

Referring again to Figure 9, the operation of the 
I/O converters was as follows (Sylvania 19596): 

1. When the I/O instruction was read from 
memory and placed in MOBlDic’s instruction reg- 
ister, it was decoded and the desired I/O device 
status was sensed. If the device was busy, the 
MOBIDIC TF counter was stopped at TF-8 until the 
device was free. Since this halted computation 
whenever a busy device was addressed, it was 
normal for the program to first sense device sta- 
tus with one of the sense commands before issu- 
ing an I/O instruction. When the program reached 
a point where it had to wait for this I/O device 
to become available, the I/O instruction could be 
given and the mobidic computer would wait until 
the device was available, issue the I/O order, and 
then proceed. 


% | 
i I 

f J 
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2 ‘ Whei1 the I/O device was free, bits 1 through 
36 of the instruction were passed over the main 
transfer bus in the following way: 

Bits 22 to 30 [ k ] were placed in the word block 
counter [WBC] where bit 30 acted as the word 
block flip-flop and the remaining 8 bits served 
as the block counter, decrementing by one for 
each word or block that was processed. 

Bits 31 to 36 specified the instruction type and 
were passed to the instruction register [ISR], 
Bits 16 to 21 went to the device address reg- 
ister [DAR] and identified the I/O device. 
Bits 1 to 15 (a) went to the address counter 
[ADC] and were incremented by one for each 
memory access. When these bits specified a 
register address, the ADC was not stepped. 
The no halt on converter error [NHC] flip- 
flop and interpret sign [ISN] flip-flop were 
set m the converter to conform with their 
corresponding flip-flops in mobidic. They 
were involved in alarm and error conditions 
and are not shown in Figure 9. 


3. Data were moved from and to mobidic 
through the buffer and when it was ready for 
transfer, signal [CB] was set. The signal was 
sensed during TF-8 of the mobidic basic cycle as 
well as at regular intervals during all long in- 
structions which meant that extended operations 
such as multiply, divide, repeat-move could not 
block I/O transfers by any longer than 22 micro- 
seconds. When several I/O converters were ac- 
tive, these signal lines were sensed in the follow- 
ing priority order: real-time system, magnetic 
tapes, and other I/O devices. The sensing order 
gave priority to the lowest numbered unused con- 
verter. 

4. The CIR register was used to interchange 
characters with the buffer. It translated octal to 
Fieldata code and back, sensed the sign bits in 
numeric words and put them in the right form, 
and generated the needed parity and control bits. 

5. Characters were transferred rapidly from CIR 
t ough BSR, BXR, and TAR on writing, and in 
the reverse direction on reading. These registers 
were used solely for buffering purposes. 

6. The N counter [192] counted the character 
transmissions and set the CR flip-flop when a 
memory transfer was required. 

'flie operation of the converter was controlled 
by its own timing logic and timing counter, Theta. 
This 2-bit counter stepped through its four pos- 


Jblestates in the Grey code sequence: 00, 10, j j 

Since the mobidic word was composed of 36 bi- 
nary bits plus one sign bit, some transformation' 
was required before this information could be in, 
terchanged with the 81/0 devices which dealt in 
8-bit characters. The transformation was per 
formed in the converter’s CIR register as follows: 

/ 

1. Each word was broken into six characters of 6 
bits each. 

2. A seventh control bit was added by the con- 
verter to indicate to the I/O devices and the 
converter whether the character was for data 
or control. 

3. A parity bit was generated and checked by the 
converters. 


When the data being transferred were purely 
numeric, it included a 37th bit for the sign which 
was handled by adding a seventh character. When 
the information was alphanumeric, either six or 
seven characters were needed and the sign bit of 
the mobidic word was either ignored or trans- 
formed into a full character, depending on the state 
of the interpret sign [ISN] flip-flop. This trans- 
formation process was also controlled by the I/O 
instruction in the ISR Register (Table 15) (Syl- 
vama 19595). For example, for the write alpha- 
numeric (WAN) instruction, each processor word 
of six characters and one sign bit produced seven 
output characters in the interpret sign mode and 
six in the noninterpret sign mode. 

The device switching units [DSU] shown in 
Figure 9 connected to each I/O device [120] 
through an amplifier that matched the signal lev- 
els. Each device had one DSU for each converter 
so, for example, a system with three converters 


Table 15. mobidic I/O Character Sizes 


Op Code 

Bits/Char. 

Processor 

Characters/ 

Word 

WAN 

6 + 1 Sign/Word 

ISN = 1: 7 

WWA 

6 + 1 Sign/Word 

ISN = 0: 6 
ISN = 1: 7 

RAN 

6+1 Sign /Word 

ISN = 0: 6 
ISN = 1:7 

RAV 

6 + 1 Sign/Word 

ISN = 0: 6 
ISN = 1:7 

WOK 

ROK 

3 + 1 Sign/Word 

3 + 1 Sign /Word 

ISN = 0: 6 
13 

13 
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^ht devices would have a total of 24 DSUs. 
DSUs connected to their respective con- 
s through a 22-conductor converter bus 
transmitted both data and control infor- 
: back and forth between the units. These 
tions were: 


100,000 reached stages 31 to 36 of RIR and, 
upon receipt and shifting of the next character 
into RIR, the read line was dropped, the busy 
bit flip-flop set to cause memory transfer, and 
the RAR incremented by one. 


lines 17 through 22 connected to the address 
jj^oder in the DSU. When they contained the 
g_bit address of that DStPs device, a signal was 
to DSU control [200], which activated the 


Interpret Sign Mode 

This mode was initiated by the mobidic program 
by setting the real-time interpret sign flip-flop, 
RISN, prior to receipt of any data. Operation was 
exactly the same as in the noninterpret sign mode 
except that seven characters were formed into each 
word. The first character was supposed to be either 
110,000 or 110,001 for 0 or 1, respectively, and if 
it was not, characters would continue to be re- 
ceived until a character was shifted into the sev- 
enth position that had a 1 in RDl^. When this 
occurred, the next character completed the word, 
and memory transfer occurred as above. 


!_ When the DSU was activated, data on lines 9 
through 16 of the bus were connected by the 
data switch to the matching amplifier. Since 
the converter bus and the matching amplifier 
both sent and received 8-bit characters over 
these same connections, either their driving or 
their sensing circuits were activated, depend- 
ing on the command being executed. 

| Lines 1 through 8 of the bus carried the con- 
trol information and signaled the type of op- 
eration to be performed. The DSU control cir- 
cuitry handled device timing and control in 
response to the command signals from the con- 
verter for starting, stopping, and data trans- 
mission. The DSU also provided strobe and er- 
ror signals to the converter. 


Control Character Mode 

Operation in this mode was as follows: 


1. The real-time input program interrupt ad- 
dressable flip-flop [RCI] was first set by the 
mobidic program. 

2. Control characters were indicated by having 
bit 7 a zero. Receipt of such a character blocked 
reception of further characters, transferred the 
RIR contents to memory, and set the control 
flip-flop [KCF], 

3. At the next mobidic t pulse, the real-time in- 
put control flip-flop [RINC] was set and KCF 
cleared. This caused a mobidic interrupt which 
took priority over all other interrupts. 


Appendix D: mobidic Real-Time Operation 


The four real-time modes of operation for the 
MOBIDIC computers were as follows (Brun et al. 
1967; Greene 1959): 


Noninterpret Sign Mode 


1. The RIR was cleared whenever a word was 
transferred to memory. The character 100,000 
was first inserted in RIR^ and the ready line 
was raised indicating readiness to receive an- 
other character. 

2. For each incoming character, parity was 
checked and the input parity error flip-flop RPE 
was set if appropriate. 

3. Each incoming character was shifted into the 
RIR, lower bits first. 

4. As each character was received, its seventh bit 
was sensed and if it was a 1, the KCF flip-flop 
was set, indicating that a control character had 
been received. 

5- The control circuitry detected when character 


Real-Time Output 

Real-time output was under MOBIDIC prograi 
control and had the same three modes as input. 


Noninterpret Sign Mode 


1. When a mobidic program instruction loaded 
the ROR, the real-time output busy flip-flop 
[ROBB] was set. 

2. When the receiving device ready line was 
raised, a character was transmitted and ROR 
was shifted left six places. 

3. When six characters had been sent, ROBB was 
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cleared, indicating to mobidic that ROR was 
ready for another word. 


Interpret Sign Mode 

For this mode, the mobidic program set the real- 
tune output interpret sign Hip-flop, ROSN, before 
loading ROR. Seven characters were then trans- 
mitted exactly as above. 


Control Character Mode 


For this mode, the real-time output control char- 
acter flip-flop, ROTC, was set before loading Rqr 
T he operation then proceeded as above, except tha 
only one character was transmitted per word and 
the mobidic program had to reload ROR for each 
control character sent. 



Happenings 

plith a. maulucci, editor 


77 , e Happenings department reports on events — 
past, present, and future — that are of particular 
Interest to the history of computing. Of primary 
importance are recent meetings that are of 
historical significance. Few meetings concentrate 
solely on history, but many contain sessions that 
can be recorded in this department. Organizers 
of historical sessions and meetings are urged to 
appoint a person with the specific responsibility 
oi writing a report and submitting it to this 
department. They are further encouraged to 
taperecord sessions and to create a photographic 
record that can be deposited with one of the 
computer archival establishments, such as the 
Charles Babbage Institute, the Computer 
Museum, or the Smithsonian Institution. 

Conference planners are specifically referred to 
Appendix B, Conference Organization, in History 
of Programming Languages (Richard L. 

Wexelblat (ed.), New York, Academic Press, 

1981), for a description of the preliminary steps 
that may be taken to obtain and record historical 
material presented in a conference setting. 

This department will also present news and 
notices of forthcoming activities that are of 
historical value. These may include conferences, 
exhibits, projects, awards, publications, and 
poneral memorabilia. Contributions should consist 
of a brief description of the activity, highlighting 
Us specific relevance. 

Finally, this department will contain citations of 
prominent dates in the history of computing. 

Readers are welcome to submit suggestions. 

These must include the day, month, and year of 
the event, and should be accompanied by a 
statement of the source used for verification. 


^th Anniversary of Committee X3 
Abstract 

^®odards within the Information Processing 
^ ave been developed and approved 
by Accredited Standards Committee 
*nd < R un< ^ er tbe auspices of the Computer 
'^BE\lA^ neSS Manufacturers Association 
' During that period over 100 standards 


Annals of 


have been published by the American National 
Standards Institute (and its predecessors) for use 
within the U.S.A. On 12 February 1986 Com- 
mittee X3 celebrated its 25th anniversary at its 
spring meeting at Infomart in Dallas, Texas. 

Introduction 

Standards within the Information Processing 
community began to be developed as early as 1961 
under the auspices of the Office Equipment Man- 
ufacturer’s Institute (OEMI), following a General 
Conference on Office Machines and Data Pro- 
cessing Machines conducted by the American 
Standards Association (ASA) in January 1960. 
That meeting, which was chaired by G. F. Hus- 
sey, Jr., Managing Director of the ASA, was at- 
tended by 47 interested persons representing 31 
organizations (see Appendix A); 11 staff mem- 
bers from the ASA also attended. Of major con- 
cern to the conference was a proposed Interna- 
tional Round Table Conference suggested by the 
International Electrotechnical Commission 1 and 
the means by which a U.S. delegation would be 
chosen. It was agreed that the "United States 
should be represented at the proposed interna- 
tional round table conference on digital com- 
puters and data processing machines.” 2 J. W. Bir- 
kenstock, representing the OEMI, reported that 
the data processing machine manufacturers were 
prepared to "pursue a standardization program 
with users for their mutual benefit.” At that time 
he also made a clear distinction between stan- 
dards which would be applicable to "components” 
as contrasted with those for "systems.” To this 
end it was proposed that an ASA committee be 
established with the following charge: 

[To develop] a single standard for logical repre- 
sentation of characters and character format in 


'This organization is listed in the original minutes as "the 
electrical branch of the International Organisation for Stan- 
dardisation [ISO]” but this is slightly incorrect. According to 
Ed. Lohse, IEC is "an independent international organization 
.which chose not to be a part of ISO when it was formed 
in 1946.” 

Minutes of the General Conference, Doc. XX 5082, (marked 
"Not for Publication”), ASA, New York NY, 13 January 1960 
p.5. In the files of Frank Verzuh, President, SHARE, Inc., in 
the archives of the Smithsonian Institution. 
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the media used for interchange of instruction, 
data, and control information between data pro- 
cessing equipments, together with orderly pro- 
vision for expansion and alternatives. [To de- 
velop] standard terminology and definition of data 
processing operations and functions. 3 

the discussion that followed it was determined 
that there were four major parts to this project 
(still apparently under the assumption that a 
single standard would r6sult)i 

• A standard character set and coded represen- 
tation. 

• A standard format for defining the meaning of 
strings of characters. 

• A common problem-oriented programming lan- 
gunge for data processing. 

• P J!u 1Se def ! mtlon of data processing operations 
at the machine level. 

The work of other organizations in the standards 
area was reviewed to determine the possible 
overlap in activities of this proposed committee, 
these organizations included: 

• Electronic Industries Association (EIA)— mag- 
netic coating, paper tape 

• American Gas Association (AGA)— systems de- 
sign 

• Association for Computing Machinery (ACM) 4 — 
a problem oriented, machine independent lan- 
guage for automatic data processing machines” 
m conjunction with CODASYL, and an "alge- 
braic language (algol)” which was also prob- 
em oriented and machine independent in con- 

T™ With GAMM (A European counterpart 
of ACM). 

J. L. McPherson of the U.S. Bureau of the Census 
was very skeptical about the chances of devel- 
oping a standard for common programming lan- 
guage, though he admitted it was desirable 
Likening such a task to that of standardizing 
Esperanto, he stated that it was "a noble cause 
but completely impractical.” 

Following the discussion three motions were 
proposed and unanimously approved: 


, Rob frt Berner remembers the first item having been in 
traduced by himself, representing CODASYL; it appears that 
the minutes were never corrected. appears tnat 


• That the General Conference recommend t 
an ASA project on Data Processing Machi 
be established. 5 

a o a* scope [ubove] be recommended to i 

AbA. 

That the OEMI be invited to accept sponsorsl 
chined Pr ° P0Sed pr ° JeCt ° n Data Pr °cessing ft 


Thus was founded the ASA Sectional Commit 
on Data Processing with the cryptic number 1 
At the same meeting, a parallel set of moth 
was proposed and passed which established 
committee for Office Machines. This commiti 
was also to be sponsored by the OEMI and u 
numbered X4. 

1Q J. he X3 committee commenced 

19bl with the following participants: 7 


• Association for Computing Machinery 

• Data Processing Management Association 
’ Department of Defense 

' General Services Administration 

ST 11 formation Systems Division 
IBM Corporation 
NCR Corporation 
Sperry/UNIVAC Corporation 


Others such as the National Bureau of Sta 
dards RCA, Burroughs Corp., and General Tin 
joined within the first year. 

Since that beginning, with the target of d 
veloping a single standard, ASA has changed ii 
name twice [to United States of America Star 
dards Institute (USASI) for a period, and no. 
American National Standards Institute (ANSI 
as has OEMI [through Business Equipment Mar 
ufacturers Association (BEMA) to Computer an, 

Jnn S ^ e A S ^ q ? Pment Manu f a cturer’s Associatioi 
(CBKMA)], though the designation X3 still ex 
ists. In 1981 the two original committees, botl 
now considerably swelled in membership, were 
combined into a single committee bearing Auer- 
bach s originally requested title "Information 
Processing Systems.” Coincident with the Su- 


7 - > 


P™? SaaC .^ U 1 erba< ; h requested that the phrase imormatio 

XZ‘% -n~ ft—™- W «*• 

?" estl0n of a "single standard” worried some attenc 
ees, but they were assured that such a phrase would suffic 
tor many years! 

From the 25th Anniversary Program. 


Mfe.! 
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m: in d that 
1 S Machinej 

Stt d to the 

sponsorship 

lce n g Ma. 


C imittee 

au 3er X3. 
of motions 
tablished a 

C( mittee 
dl id was 

lm^nced in 


e Court ruling on the Hydrolevel case, 8 ANSI 
fjgnjented its "National Policy on Standards,” 
^eby confirming its role as a private sector co- 
'^j'nator. In its 25 years of existence, the X3 
^'rnittee has taken upon itself almost 500 proj- 
1-0 and has published over 120 standards, as well 
^deleting a few along the way. The original 
' ■ man of committee X3 was Charlie Phillips, 
the chair of CODASYL. 9 On retirement in 
fq72 he was succeeded by John Auwaerter of the 
Teletype Corporation, who served for 10 years. The 
-hairman at the time of the anniversary was Ed- 
ward Lohse of the Burroughs Corporation. 

Within the engineering community the devel- 
opment of industry standards is a long-standing 
activity by means of which well-established con- 
«pts and practices are promulgated to assure 
quality and safety in products which are to be 
available in the wider public community. Infor- 
mation Processing Standards have not had the 
same impact on the practices of the profession as 


"Supreme Court of the United States, American Society of 
Mechanical Engineers, Inc. vs Hydrolevel Corp., No. 80-1765, 
Decided 17 May, 1982. 

"See the Annals, October 1985. 


have engineering standards. While fortran and 
COBOL have provided a portable environment for 
programmers, they are little appreciated. Instead 
the standards process is viewed as an activity 
which stifles expression and individuality. This 
vision of standards as coming "too early” in the 
development cycle is offset by the concern that 
standards which are "too late” can only represent 
the maximum common denominator of diverse 
implementations. Thus it is surprising that the 
standards process has lasted 25 years and seems 
to be increasing in strength as there is a recog- 
nized need for improved reliability of informa- 
tion processing systems. Since the origination of 
committee X3, other institutions have begun to 
support standards in the area; in particular the 
IEEE-Computer Society has mapped out the field 
of software engineering for standards develop- 
ment. 

The Celebration 

To mark the 25th Anniversary of the committee, 
CBEMA invited past and present representatives 
of member organizations as well as those who 
participated in technical committees to attend a 
dinner at the Infomart in Dallas, Texas. The cel- 
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u^ brati( m dinner at the Infomart in Dallas. Left to Right: John Auwaerter, Mrs. Auwaerter, Donald Peyton, 
a - Lohse, Edward Lohse, Vico Henriques, Kathy Kachurik, Max Hopper, Frances Shrotter, (not identified). 


Annals of the History of Computing, Volume 9, Number 3/4, 1988 • 347 



* 


Happenings 


ebration was attended by approximately 70 pi- 
oneers of the information processing standards 
community together with their guests. As is com- 
mon at celebrations of this kind, there were nu- 
merous anecdotal sessions surrounding the cock- 
tail bar, almost none of which were recorded for 
posterity. The after-dinner program contained 
three addresses: 

• Welcome and Charge for the Next 25 Years— 
Vico Henriques, President, CBEMA 

• ANSI and X3, Partners in Progress— Donald 
Peyton, President, ANSI 

A User’s View of Information Processing Sys- 
tems Standards— Max D. Hopper, Sr. Vice 
President, American Airlines 

Following the formal addresses the attendees were 
recognized in the order of their seniority of ser- 
vice, those with over 20 years being accorded the 
title of Pioneer (listed in Appendix B). Below are 
excerpts from the presentations by Henriques and 
Peyton, and a description of Hopper’s talk. 

Vico Henriques, President, CBEMA 

As I look around I can see that we have centuries 
of standards experience gathered in this magnif- 
icent hall and I am proud to have been a founder 
and a sometime worker in the vineyard of stan- 
dards. 

It is the anniversary of a meeting, but it is the 
celebration of the forum that allows a fantastic 
group of people to gather together in a common 
cause. The talents are many, the personalities 
unique, but the common thread is the dedication 
of each individual. Each of you, in your own way, 
know of the many contributions this collective 
body has made to technology and society. It is not 
always apparent to the public, but without those 
years of service, our industry, our nation, our very 
civilization would not be what it is today. 

The information industry has become global, 
the marketplace increasingly competitive, and the 
technology ubiquitous. Information processing 
systems standards contribute to the removal of 
trade barriers, to the balance of payments and to 
increased productivity. 

While we had lofty goals not all of those years 
were totally serious. We can all think of a mo- 
ment or two when hysteria ran wild: the Peter 
Ingerman TV experiments, Bill Rinehuls’ pizza 
parties, Charlie MacKenzie’s singing sprees and, 
of course, Bromberg’s tombstone. 



Vico Henriques delivers a challenge to X3 to look to 
the future and the next 25 years of standardization. 


As I prepared for this anniversary meeting my 
thoughts were on the past, the many friends who 
are no longer with us, and certainly the present 
and where we are today — this activity that spews 
almost 2,000 documents a year and literally costs 
millions of dollars a year to run. , 

The environment today is not at all as it was 
25 years ago. The Corporation for Open Systems, 
the MAP/ TOP users groups — all of these are new 
in the last few years. They reflect the sophisti- 
cation of the users, the need for well-defined 
standards plans, and the drive to use resources 
as effectively as possible. 

As we celebrate L^ight, we must also prepare 
for the next 25 years. We must realize that in 
1985, more than half of the gross national prod- 
uct came from service industries while less than 
20 percent came from manufacturing and agri- 
culture. Our standards provide the means for those 
service industries to incorporate new technology^ 
expand their offerings, and become more produc- 
tive and competitive. 


Annals of the History of Computing, Volume 9, Number 3/4, 1988 




] 


ktt 

>n. 



m 


m 

jut 

** 


yti 

as* 


: 



We must continue to focus on the user /sys- 
tems issues; we must continue to address the in- 
creasing international demands. Unfortunately, 
one of the problems we suffer is that the more 
mature talent is not being supplemented and re- 
placed by the younger participants. We tend to 
lose a tremendously talented individual such as 
phil Ameth or Elliott Nohr and it takes us too 
long to recover, to groom the next class, so to 
speak. 

We face the next 25 years with a wealth of ex- 
perience and talent. We must capitalize on that 
and contribute even more to the world of infor- 
mation processing systems. 


Donald Peyton, President, ANSI 

It is a pleasure to be with you to celebrate the 
25th anniversary of X3, the premier accredited 
committee in the voluntary standards system. We 
might as well give in to a bit of Jesuit modesty 
and admit that X3 is the "greatest standards 
committee of all time.” 

When I was asked to recall the history of X3 
and ANSI, I was struck with the possibility of 
taking one of two paths. The first would be that 
of the famous black baseball pitcher, Satchel Page. 
Satch always gave the advice to his followers to 
"never look back — they might be gaining on you.” 
The other path, and frankly the preferred, is the 
advice of George Santayana who wrote: "Those 
who cannot remember the past are condemned to 
repeat it.” 

Tonight I want to take a look back — to re- 
member some of the past, some of the experi- 
ences we have had, in order that we will not re- 
peat the less productive and can concentrate on 
the fantastic future which I believe lies ahead for 
the X3 Committee, ANSI, and the voluntary 
standards system. 

1986 is an off-year election in which the entire 
ouse of Representatives and one-third of the U.S. 
na *; e be elected. If the American public fol- 
0Ws its normal course and if we are as compla- 
int as usual, we could relive the political disas- 
. .1958, which led the way to a change in 
•v fc ras * Ta ti° n in 1960. More important it brought 
-return of the anti-business, pro-big govem- 
fn&ulatory hordes that had been lying in 
Wnt Tj ei S ht long years of the quiet, compla- 
in . 1 at ° r y Eisenhower administration. I can 
Am f • °* ln Kenned y exhorting the public to 
the moy i n g again.” Little did they know 

tons that "move” would take. 
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1961 brought a number of remarkable people 
to government. It was the awakening of much of 
the scientific and technical community and the 
start of a number of programs in which this great 
nation is now the world leader. Unfortunately, 
along with the good came the so-called govern- 
ment activists who believed that only the gov- 
ernment could (or should) develop and carry out 
programs in the public interest. The populists 
found a home in the new administration. 

When the Office Equipment Manufacturers 
Institute (which was soon to become BEMA) 
formed the X3 Committee in 1960-61 it took a 
giant step to head off government intervention in 
the field of data processing. 

In 1961 I had just left Capitol Hill to work for 
the U.S. Chamber of Commerce. Among my re- 
sponsibilities were the assessment of proposed 
government programs in science and technology 
and the general area of domination or regulation 
of science and technology by government. Be- 
lieve me, the Chamber’s Science and Technology 



Donald Peyton congratulates X3 on 25 years of stan- 
dards. 



r 
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Committee had a full plate. In less than a year 
the administration and Congress were well on 
their way to massive technical regulatory efforts 
in automotive and highway traffic safety, envi- 
ronmental protection, consumer product safety, 
occupational safety and health, plus tighter con- 
trol of such service industries as transportation 
and communication and — believe it or not — even 
the beginnings of government-sponsored com- 
missions to determine the future of both national 
and international standards development. Some 
of you may remember the Kelly Report and the 
LaQue Report, which finally triggered a volun- 
tary counterattack which apparently worked. 

In 1961 the voluntary standards system and 
its coordinating organization, the American 
Standards Association (ASA), were in very poor 
condition and either unable or unwilling to pro- 
vide the leadership necessary to effectively com- 
bat an aggressive government assumption of 
public interest and international standards. The 
government knew little about or paid much at- 
tention to general engineering or commodity 
standards. Hence the large technical societies such 
ASTM, SAE, IEEE were not threatened until the 
mid-1960s, and even then only slightly. The sworn 
enemy of the populist regulators was industry self- 
regulation and, of course, the consensus system 
under which self-regulation flourishes. 

Unfortunately, the voluntary (consensus) sys- 
tem had fallen into general disuse, decay. It had 
been virtually abandoned by both the founding 
societies and the growing number of trade asso- 
ciations and industrial groups established to per- 
form services needed by industry, including de- 
veloping industry standards which might 
eventually become national or international in 
scope and use. A look back at the history of ASA- 
BEMA shows quite clearly that the prevailing 
system of funding ASA through contributions of 
trade associations — rather than direct corporate 
membership— had resulted in a confrontational, 
even a competitive relationship. 

While progress was being made in develop- 
ment of data processing standards, and in other 
fields as well, the prevailing philosophy in gov- 
ernment was one of eventual assumption of stan- 
dards develops °nt, hv rrovernment. How could it 
be otherwise.'' We had an ongoing product stan- 
dards program in the National Bureau of Stan- 
dards which had the support of many of the 
smaller trade associations. We had the initiation 
of the space program and new life for the mili- 
tary-industrial complex which demanded more arid 



more "milspec” or "NASA-unique” solutions. W 
had the labor movement champing at the bit to 
enact an Occupational Safety and Health Art 
based on government-developed standards. We had 
the newly emerging Naderites and other pu^c 
interest groups telling us continuously how in 
adequate existing industry standards were, how 
poor the protection of the public was, and how 
essential it was to pass the baton over to the bu- 
reaucrats. We also had a Congress which had al 
ready proven its willingness to spend and SD en,i 
and elect and elect. 

Against this tide of adversity, how did the vol- 
untary standards .system survive? Why are we able 

to celebrate 25 years of progress and look ahead I 

to even more productive efforts in the years ahead’ 

What brought the turnaround? Surely it was • j 
not the public. They couldn’t care less. They hardly , 

recognize standards. They have come to expect I 

the best. It was not a change of heart in govern- ( 

ment. Not in the decade of the sixties. 

It was actually a combination of factors. Re- 
sponsible industry did not support the growth in i 

government fostered by the incumbent adminis- 
tration. Industry was very worried about the i 

"brain drain” and preemption of scientific and < 

technical manpower required by massive space c 

and military programs. Industry began to rebel t 

against insidious policies of government to as- c 

sume title to patents in government R&D and to ! 

deny or limit the patent protection of proprietary i 

products, particularly pharmaceuticals. The pat- i 

ent system was definitely under attack. : ■’’•r < 

Fortunately industry did not lose faith in the ( 

value of standards as essential tools of commerce 
and industry. With the emergence of Europe and ' c 

the Japanese as competitors in world trade, in- s 

dustry became very serious in its support for sound - - i 

industrial standards — and gave its support to < 

BEMA/X3 and other related areas. In the tele- ( 

communications field, industry had long been the 
source of necessary standards. ; 

The Board of ASA began an in-depth exami- ( 

nation of the standards system and the future of ' 

the organization. This study was conducted in j 

parallel with that of the U.S. Department of < 

Commerce under the chairmanship of Dr. Frank 1 

LaQue. In the end it became clear that drastic , . ' 

actions would be required if the private sector 1 

were to keep the standards system largely if r ' nf . ( 

exclusively voluntary. The critical decision fac- 
ing the participants was whether to simply aban- 
don the ASA and build a new institution to as- ; .. a ( 

sume its programs or to build on the basic i 
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principles of ASA but restructure its operations, 
policies, procedures and methods of financing its 

operations. 

Early in 1964 the Chairman of General Elec- 
tric Company 10 called a meeting of some 20 lead- 
ing industrial concerns, including the leaders in 
standards in data processing, electrical manufac- 
turing, automotive, petroleum, chemicals and 
telecommunications. The question of support for 
a restructured ASA was put to those who at- 
tended. In addition a fund was raised to bail out 
the ASA and enable it to meet its payroll. 

By 1966 it was apparent both inside and out- 
side ASA that the volunteers and sponsoring or- 
ganizations such as BEMA were keeping the 
remnants of ASA alive. Staff morale in ASA was 
at its lowest ebb. What technical staff did exist 
was assigned largely to "fire drills” aimed at pro- 
tecting existing sources of income and a few highly 
questionable contracts. Support staff, editorial, 
public information, administrative were magnif- 
icent. They kept things going with little personal 
reward and a great deal of personal sacrifice. 

When I was approached on the possibility of 
assuming responsibility for management of the 
organization — by now known as the United States 
of America Standards Institute (USASI) — the fu- 
ture was far from rosy. I called on a number of 
companies represented at this celebration and a 
number of your companies called on me. I will 
never forget our good friend, Charlie Phillips, who 
visited me to let me know what needed to be done 
to support X3 and ISO standards. (This visit in- 
cidentally came before I agreed to move to New 
York.) Charlie’s problem was that he, and a lot 
of others, were very impatient . . . and well they 
should have been. The level of support from ASA 
was far from adequate even though it probably 
approximated the level of support from the in- 
dustry to ASA at the time. 

At first we believed that an infusion of capital 
and a healthy increase in organizational and 
company dues would cure most of the ills. This 
was naive. The essential element lacking, which 
T° n became a critical mass, was a public review, 
e proeess^ system for approval of standards. The 
u 0 bu e process was not discovered by vol- 
arv organizations — most of them were very 
easy about any public review. The clarion call 
e om a long series of hearings which ulti- 


mately resulted in passage of the Gas Pipeline 
Safety Act which, among other provisions, called 
for a government commission to set safety stan- 
dards. The testimony presented in those hearings 
was ample evidence that the USASI organization 
had to alter its coordination and approval pro- 
cedures to provide public review and comment on 
proposed standards. 

The process as we know it today became fully 
operational in 1971. The prediction was that there 
would be a dropoff in submittals. In fact, the 
number of cases completed each year now aver- 
ages 2,400. The year before BSR was established 
ANSI processed 200 standards. 

The voluntary system now enjoys a high de- 
gree of credibility. Attacks on the system are met 
head on with evidence of due process. There is no 
doubt in my mind that the four-year effort by the 
Federal Trade Commission to write a Trade Reg- 
ulation Rule for Standards 11 was beaten by the 
fact that even the proponents could not argue 
successfully that they did not have ample oppor- 
tunity to participate, to make their views known, 
and to appeal any or all decisions. 

Improvements in the approval process, and re- 
vision of methods for developing and coordinat- 
ing standards to place primary responsibility with 
accredited organizations and accredited commit- 
tees (such as X3) has attracted the voluntary co- 
operation and participation of some 250 trade, 
technical, scientific, labor, consumer and govern- 
mental organizations. These aggregate 90 to 95 
percent of the nongovernmental standards de- 
velopment in the United States. Organizations do 
not join and work with ANSI because they have 
to, they do it voluntarily. 

The government attitude toward voluntary 
standards and ANSI has turned around. ANSI 
works with a myriad of agencies. It has ongoing 
coordinating committees with OSHA and CPSC 
and informal arrangements with many others. 

In 1984 ANSI received the Presidential Pri- 
vate Sector Initiative Commendation for its Vol- 
untary Self-Regulation Program. It was the only 
standards organization to receive the Presiden- 
tial Commendation. 

Even though we may be in a period of "remis- 
sion” from regulation, the record of service to 
government departments and agencies and the 
response to public interest needs will make it dif- 


£t 1 


psny in iqco rma ” the Board of General Electric Com- 
801 appear Was ^!: ra *h L. Phillippe, though his name does 
any of the files that we searched. 


“See: Lee, J. A. N., "Response to the FTC Proposed Ruling 
on Standards and Certification,” Comm. ACM, Vol. 24, No. 
6, June 1981, pp. 375-380. 
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ficult for government to mount any new FTC or 
legislative efforts to control or regulate our pro- 
grams or the voluntary standards system. With- 
out the support of the data processing industry 
and the X3 Committee, this record of achieve- 
ment would not have been possible. 

In 1986 ANSI and X3 are facing a virtual del- 
uge of new standards demands, mostly applica- 
tion or subset standards. We find ourselves iden- 
tifying such organizations and programs as the 
Automotive Industry Action Group, Electronic 
Data Interchange Institute, Automatic Identifi- 
cation Manufacturers, Federation of Automated 
Coding Technologies, Robotics Institute of Amer- 
ica, Exchange Carriers Standards Association, 
MAP, TOP, and most recently the Corporation 
for Open Systems. 

Max D. Hopper, Sr. Vice President, American 
Airlines 

Max Hopper surveyed the field of computer stan- 
dards from the point of view of a user, and es- 
pecially the impact on American Airlines. He 
looked back to the SAGE system and surmised that 
innovation of that type eventually led to stan- 
dards for others to build upon. He congratulated 
the Committee and its sponsor CBEMA on a job 
well done and looked forward to more help in the 
form of standards from the Committee. 


Summary 

The 25 years of the X3 committee and the stan- 
dards "business,” which has now been joined by 
other players, is more than just its start in 1961 
and its 25th anniversary in 1986. In between there 
have been successes and failures; the early stan- 
dards for ASCII, fortran and COBOL were among 
the successes; the inability to get approval for the 
I/O interface was the epitome of failure. As men- 
tioned by Donald Peyton, the rejection of the reg- 
ulation of standards developers by the FTC and 
the proposed requirements for reporting and ex- 
treme accountability was a clear success. This 
success was partially the result of the implied 
agreement made by ANST witne^pq at tho ptq 
hearings that many of the requirements which 
were to be imposed by the regulations would be 
included in a revision of the standards develop- 
ment procedures used as the model for the pro- 
cedures for individual development organizations 
such as CBEMA and IEEE. It is not clear that 
all of the precepts of openness and involvement 



Max Hopper urges X3 to consider the user. 


\a - ... ' i 1 . ■ • 

of all interested parties expected by the FTC has 
yet been achieved. 

The development of standards for specific ob- 
jects and concepts in the information processing 
area is a methodology which incorporates the 
recognition of existing technology (in the form of 
existing implementations), the management of 
consensus procedures, and the infusion of. politi- 
cal maneuvering. It is difficult to separate stan- 
dards development from product development in 
many instances; where there is such a separa- 
tion, then it generally means that the standards 
process is preceding the implementation and the 
standard is likely to be classified as one which 
will stifle innovation. Four rln==i<- examples are 
the development of ASCII, DES (Discrete En- 
cryption Standard), COBOL and Ada, 12 though this 
reporter might argue that in the latter two cases 
the actual development activity only produced 



12 Ada is a Trademark of the U.S. Government, Ada Joint 
Program Office. - ^ 
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documents that were later candidates for stan- 
dardization. Perhaps it is also significant that in 
each of these cases the U.S. Government was in- 
timately involved in the development process! I 
hope that the history of these developments will 
be published, not simply as an appendage to the 
technical development but as a important part of 
that development. 


Acknowledgments 


Being a part of history is much more work than 
being a reporter on someone else’s 25 years, I have 
discovered. When dealing with history from an 
outsider’s point of view, the source of data is the 
documentation left behind and the memories of 
others (which can be used in a voting procedure 
to elicit the "truth”); when dealing with your own 
memories it is difficult to be convinced that doc- 
umentation is more correct than personal mem- 
ory. In the case of Committee X3 the problem is 
an overabundance of documentation — but most 
of it is not historically important yet. When we 
are ready to write a history of the impact of stan- 
dards on the computing world, that documenta- 
tion will be invaluable. This report is based on 
the memories of those who helped me remember 
and who were pioneers themselves; my thanks to 
them for sharing in this experience: Robert Be- 
rner, Vico Henriques, William Rinehuls, Donald 
Peyton, Edward Lohse, and John Auwaeter. 


Appendix A. Attendees at the ASA General 
Conference ’ 3 


Corporate and Institutional Representatives 


Air Transport Association of America 
J. B. McGuire 

American Bankers Association 
M. C. Miller 

American Gas Association 
T- J. Shanley 
B. Towle 

American Gear Manufacturers Association 
E - V. Carlson 

merican Institute of Electrical Engineers 
”• R- Lenz 

Computing Devices Committee 
R M. Kalb 


^Tak 

from the Minutes of the 13 January, 1960 meet- 
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Systems Engineering Committee 
W. C. Marble 

American Petroleum Institute 
E. F. Koenig 

The American Society of Mechanical Engineers 
Industrial Regulators Division 
W. D. Archibald 

American Society for Testing Materials 
P. S. Olmstead 
Armour Research Foundation 
G. T. Jacobi 

ASA Sectional Committee X2, Office Standards 
E. F. Cohen 
R. Hutchinson 
J. Murphy 

ASA Sectional Committee Z39, 

Standardization in the field 
of Library Work and Documentation 
R. E. Kingery 

ASA Task Group Y14.15-1, Electronics and Com- 
munications 
J. J. O’Farrell, Jr. 

Association of American Railroads 
T. J. Lamphier 

Association for Computing Machinery 
Mandalay Grems 
Burroughs Corporation 
R. J. Abele 

Committee 14 on Data Systems Languages 
R. W. Bemer 

Electronic Industries Association 
A. B. Credle 
V. M. Graham 

General Services Administration 
G. E. Barthel 

Institute of Radio Engineers 

R. D. Elbourn 

International Business Machines Corporation 
Federal Systems Division 
W. F. Schilling 

National Bureau of Standards 

S. N. Alexander 
R. D. Elbourn 15 

National Joint Computer Committee 

I. L. Auerbach 

National Machine Accountants Association 
John Buhr 

Office Equipment Manufacturers Institute 

J. W. Birkenstock 


I Eli 


: -f-y 

: ill 


“There is some disagreement as to whether at the time of 
the meeting the name was "Conference on . . or "Com- 
mittee on . . The minutes use the latter phrase. 

15 Serving in two capacities. 
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T. M. Butler 
J. T. Davidson 

U. C. S. Dilks 
W. C. Doud 
R. Haney 

H. J. Hoging 
C. P. Ray 
W. J. Suchors 
E. D. Taylor 
A. J. Weitzel 

Radio Corporation of America 
R. R. Waller 
Telephone Group 
J. J. Murphy 
Underwood Corporation 
J. L. Hillis 

U.S. Bureau of Census 
J. L. McPherson 
U.S. Post Office Department 
E. S. Norton 

Western Reserve University 
J. W. Perry 
Guest 

W. H. Offenhauser, Jr. 

ASA Staff 

Managing Director: G. F. Hussey, Jr., Chairman 
Deputy Managing Director: Cyril Ainsworth 
Technical Director: J. W. McNair, Vice-Chair- 
man 

Director of Public Relations: Kenneth G. Ells- 
worth 

Chemical Engineer: C. E. Hilton 
Civil Engineer: H. Warner Dailey 
Civil Engineer: F. C. Frost 
Electrical Engineer: S. David Hoffman 
Mechanical Engineer: Sidney W. Taylor 
Staff Engineer: V. G. Grey, Secretary 
Staff Engineer: M. A. Pisciotta 

Appendix B. X3 Pioneers 16 

John Auwaerter, Retired (previously represented 
Teletype Corporation), 25 years, Chairman 
1972-1982 

Robert Berner (previously with IBM Corp., univac 
Corp., General Electric Corp., and Honey- 
well Information Systems), 25 years 
James Burrows, National Bureau of Standards, 
24 years 


16 Taken from the program; attendees with 20 or more years 
of service. J 



Eric Clamons, Retired (previously represented 
Honeywell Information Systems), 23 years ^ 
Richard Gibson, AT&T Corp., 21 years 
Vico Henriques, CBEMA (previously with Gen 
eral Services Administration), 25 years 
Cathie Kachurik, CBEMA (previously with De- 
partment of Agriculture), 22 years 
Thomas Kern, NCR Corporation, 25 years 
John A. N . Lee, Association for Computing M a 
chinery, 21 years 

Edward Lohse, Burroughs Corporation, 25 years 
Thomas McNamara, Honeywell Information Sys- 
tems, 25 years * 

Donald Peyton, ANSI, 20 years 
William Rinehuls, General Services Administra 
tion (Previously with the Department of De- 
fense), 24 years 

Robert Rountree, National Bureau of Standards 
21 years ’ 

Thomas Steel, SHARE (employee of AT&T Corp ) 
24 years ’ 

John Wheeler, Xerox Corporation, 23 years 
J. A. N. Lee 

Department of Computer Science 
Virginia Tech 

Blacksburg, Virginia 24061, USA 


The Code-Breaking Computers of 1944 

On 26 March 1987 , the Colossus designers and 
builders were gathered together once again, in 
London, by the Institution of Electrical Engi- 
neers (IEE) for an afternoon of presentations and 
discussion, followed by an evening lecture in which 
the utilization of the machine in the breaking of 
the German High-Grade cyphers was described 
by Harry Hinsley. The two meetings were spon- 
sored by the Science, Education, and Technology 
Division of the IEE. The afternoon sessions on 
the Colossus were organized by Professional Group 
7 (History of Technology) under the leadership of 
R. W. Bums, and the evening Divisional Lecture 
was chaired by I. F. Chrishop, ADC RN. 

While many in the audience anticipated new 
revelations with respect to both the construction 
of the Colossus and the use of the various Bletch- 
ley Park machines (Bombes, the Robinson ma- 
chines, and Colossus) in code breaking, they were 
to be disappointed. Even at the evening session, 
where the Colossus builders took the opportunity 
to query Hinsley on aspects of the use of the ma- 
chine which they had built, no 
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Appendix I. EBCDIC and Other Codes 


The following table shows the Extended Binary- 
Coded-Decimal Interchange Code (EBCDIC) and 


Dec 

Hex 

EBCDIC 

AS- 

CII 

ISO (1) 
-8 IBM 

-PC 

BookMaster 

Symbol Names (2) 

0 

00 

NUL 

NUL 

NUL 

NUL 



1 

01 

SOH 

SOH 

SOH 

SOH 

© 

face 

2 

02 

STX 

STX 

STX 

STX 

• 

FACE 

3 

03 

ETX 

ETX 

ETX 

ETX 


HEART 

4 



EOT 

IB] 

EOT 

♦ 

DIAMOND 

5 

05 



* 

CLUB 

6 



ACK ACK ACK 

* 

SPADE 

7 

07 


BEL 

BEL 

BEL 

• 

bullet 

8 

08 

GE 

BS 

BS 

BS 

V 

revbul 

9 

09 

SPS 

HT 

HT 

HT 

o 

circle 

10 

0A 

RPT 

LF 

LF 

LF 

1 

revcir 

11 

0B 

VT 

VT 

VT 

VT 

3 

male 

H 


FF 

FF 

FF 

FF 

9 

female 



CR 

CR 

CR 

CR 

J> 

notel8 

14 

0E 

SO 

SO 

SO 

SO 

i 

notel616 

15 

OF 

SI 

SI 

SI 

SI 

o 

sun 

M 



m 

DLE 

HI9 

► 

rahead 

Bq 



m 

DC1 

DCl 

◄ 

1 ahead 


ul 



DC2 


* 

udarrow 


M 


H 

DC3 


it 

dblxclam 

20 

14 

RES/ENP 

DC4 

DC4 

DC4 

If 

par 

21 

15 

NL 

NAK 

NAK 

NAK § 

section 

22 

16 

BS 

SYN 

SYN 

SYN 


overline 

23 

17 

POC 

ETB 

ETB ETB I 

udarrowus 

24 

18 

CAN 

CAN 

CAN 

CAN 

t 

uarrow 

25 

19 

EM 

EM 

EM 

EM 

1 

darrow 

26 

1A 

UBS 

SUB 

SUB 

IFS 

-» 

rarrow 

27 

IB 

CU1 

ESC 

ESC 

ESC 

«- 

1 arrow 

28 

1C 

IFS 

FS 

IFS 

DEL 


lnotusd 

29 

ID 

IGS 

GS 

IGS 

GS 

e 

1 rarrow 

30 

IE 

IRS 

RS 

IRS 

RS 

▲ 

uahead 

31 

IF 

ITB/IUS 

US 

IUS 

US 

▼ 

dahead 


other codes. Details are in the notes on page 1-4. 


Dec 

Hex 

EBCDIC 

AS- 

CII 

ISO 

-8 

(i) 

IBM-PC 

BookMaster 

Symbol Names (2) 

32 

20 

DS 

SP 

SP 

SP 


33 

21 

SOS 

J 

J 

J 

xclam 

34 

22 

FS 

II 

II 

II 

sdq 

35 

23 

WUS 

# 

# 

# 

numsign 

36 

24 

BYP/INP 

$ 

$ 

$ 

dollar 

37 

25 

LF 

% 

% 

0, 

percent 

38 

26 

ETB 

& 

& 

& 

amp 

39 

27 

ESC 

1 

' 

1 

ssq(3) 

40 


SA 

( 

( 

( 

1 par 

41 


SFE 

) 

) 

) 

rpar 

MB 

2A 

SM/SW 

* 

* 

* 

asterisk 

m 

2B 

CSP 

+ 

+ 

+ 

pi us 

44 

2C 

MFA 




comma 

45 

2D 

ENQ 

- 

- 

- 

hyphen or minus 

46 

2E 

ACK 




period 

47 

2F 

BEL 

/ 

/ 

/ 

divslash or slash 

48 



0 

0 

0 


49 

31 


1 

1 

1 


50 

32 

SYN 

2 

2 

2 


51 

33 

IR 

3 

3 

3 


52 

34 

PP 

4 

4 

4 


53 

35 

TRN 

5 

5 

5 


54 

36 

NBS 

6 

6 

6 


55 

37 

EOT 

7 

7 

7 


56 

38 

SBS 

8 

8 

8 


57 

39 

IT 

9 

9 

9 


58 

3A 

RFF 




colon 

59 

3B 

CU3 

s 

; 

; 

semi 



DC4 

< 

< 

< 

it 

m 


NAK 

= 

= 

= 

eq 

62 

3E 


> 

> 

> 

gt 

63 

3F 

SUB 

7 

7 

7 

quest 


Control-Character Representations 


ACK 

Acknowledge 

ENP 

Enable Presentation 

ITB 

Intermediate Transmission 

SBS Subscript 

BEL 

Bell 

ENQ Enquiry 


Block 

SEL Select 

BS 

Backspace 

EO 

Eight Ones 

IUS 

International Unit Separator 

SFE Start Field Extended 

BYP 

Bypass 

EOT 

End of Transmission 

LF 

Line Feed 

SI Shift In 

CAN 

Cancel 

ESC Escape 

MFA 

Modify Field Attribute 

SM Set Mode 

CR 

Carriage Return 

ETB 

End of Transmission Block 

NAK 

Negative Acknowledge 

SO Shift Out 

CSP 

Control Sequence Prefix 

ETX 

End of Text 

NBS 

Numeric Backspace 

SOH Start of Heading 

CU1 

Customer Use 1 

FF 

Form Feed 

NL 

New Line 

SOS Start of Significance 

CU3 

Customer Use 3 

FS 

Field Separator 

NUL 

Null 

SPS Superscript 

DCl 

Device Control 1 

GE 

Graphic Escape 

POC 

Program-Operator 

STX Start of Text 

DC2 

Device Control 2 

HT 

Horizontal Tab 


Communication 

SUB Substitute 

DC3 

Device Control 3 

IFS 

Interchange File Separator 

PP 

Presentation Position 

SW Switch 

DC4 

Device Control 4 

IGS 

Interchange Group Separator 

RES 

Restore 

SYN Synchronous Idle 

DEL 

Delete 

INP 

Inhibit Presentation 

RFF 

Required Form Feed 

TRN Transparent 

DLE 

Data Link Escape 

IR 

Index Return 

RNL 

Required New Line 

UBS Unit Backspace 

DS 

Digit Select 

IRS 

Interchange Record Separator 

RPT 

Repeat 

VT Vertical Tab 

EM 

End of Medium 

IT 

Indent Tab 

SA 

Set Attribute 

WUS Word Underscore 

Formatting-Character Representations 





NSP 

Numeric Space 

SP 

Space 

RSP 

Required Space 

SHY Syllable Hyphen 
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EBCDIC (4) 


AS- 

ISO 

IBM 

BookMaster 

Dec 

Hex 

81C 

94C 

037 

500 

1047 

CII 

-8 

-PC 

Symbol Names(2) 

64 

40 

SP 

SP 

SP 

SP 

SP 

0 

0 

0 

atsign 

65 

41 

RSP 

RSP 

RSP 

RSP 

RSP 

A 

A 

A 


66 

42 



a 

a 

a 

B 

B 

B 

ac 

67 

43 



a 

a 

a 

C 

C 

C 

ae 

68 




a 

a 

a 

D 

D 

D 

ag 

69 




a 

a 

a 

E 

E 

E 

aa 

70 




a 

a 

a 

F 

F 

F 

at 

71 

l 



a 

a 

A 

G 

G 

G 

ao 

72 

48 



Q 

S 

S 

H 

H 

H 

cc 

73 

49 



n 

n 

n 

I 

I 

I 

nt 

74 

4A 


i 

t 

[ 

t 

J 

J 

J 

cent, lbrk 

75 

4B 






K 

K 

K 

period 

76 

4C 

< 

< 

< 

< 

< 

L 

L 

L 

It 

77 

4D 

( 

( 

( 

( 

( 

H 

M 

M 

Ipar 

78 

4E 

+ 

+ 

+ 

+ 

+ 

N 

N 

N 

plus 

79 

4F 


1 

i 

I 

i 

0 

0 

0 

vbar, xclam 

80 


& 

& 

& 

& 

& 

P 

P 

P 

amp 

81 

51 



e 

e 

e 

Q 

Q 

Q 

ea 

82 

52 



§ 

e 

e 

R 

R 

R 

ec 

83 

53 



e 

e 

e 

S 

S 

S 

ee 

84 

54 



e 

e 

e 

T 

T 

T 

eg 

85 

55 



f 


l 

U 

U 

U 

ia 

86 

56 



T 

l 

l 

V 

V 

V 

ic 

87 

57 



i' 

i' 

i' 

W 

W 

w 

ie 

88 

58 



i 

T 

l 

X 

X 

X 

ig 

89 

59 



8 

8 

8 

Y 

Y 

Y 

SS 

90 

5A 


1 

1 

] 

1 

Z 

Z 

Z 

xclam, rbrk 

91 

5B 


$ 

$ 

$ 

$ 

[ 

[ 

[ 

dollar, lbrk 

92 

5C 

B 

B 

n 

fl 

a 

\ 

\ 

\ 

asterisk, bslash 

93 



B 

B 

B 

KM 

] 

] 

] 

rpar, rbrk 

94 

5E 

H 

Kfl 

B 

If 

Kg 


A 

A 

semi , hat 

95 

5F 

■ 

B 

B 

H 

H 

- 

- 

- 

lnot, hat, us 


Dec 

Hex 

81C 

EBCDIC (4) 
94C 037 500 

1047 

AS- 

CII 

ISO 

-8 

IBM 

-PC 

BookMaster 

Symbol Names (2) 

96 

60 

- 

- 

_ 

- 

- 

- 

- 

- 

hyphen or minus. 











grave 

97 

61 

/ 

/ 

/ 

/ 

/ 

a 

a 

a 

divslash or slash 

98 




A 

A 

A 

b 

b 

b 

Ac 

99 




A 

A 

A 

c 

c 

c 

Ae 

100 

64 



A 

A 

A 

d 

d 

d 

Ag 

101 

65 



A 

A 

A 

e 

e 

e 

Aa 

102 

66 



A 

A 

A 

t 

t 

f 

At 

103 

67 



A 

A 

A 

9 

g 

g 

Ao 

104 

68 



Q 

g 

Q 

n 

H 

n 

Cc 

105 

69 



N 

N 

N 

H 

Kfl 

H 

Nt 

106 

6A 


1 

1 

1 

1 

1 

1 

1 

1 

j 

j 

j 

splitvbar 

107 

6B 

• 





k 

k 

k 

comma 


6C 

B 

B 

B 

B 

|| 

n 


H 

percent 

109 

6D 


B 

B 

B 





US 

110 

6E 


B 

B 

B 

n 




gt 

111 

6F 

B 

B 

B 

B 

u 




quest 

112 

70 



0 

0 

0 

P 

P 

p 

OS 

113 

71 



E 

E 

E 

9 

q 

q 

Ea 

114 

72 



E 

E 

E 

r 

r 

r 

Ec 

115 

73 



E 

E 

E 

s 

s 

s 

Ee 

116 

74 



E 

E 

E 

t 

t 

B 

Eg 

117 

75 



1 

I 

I 

u 

u 

D 

Ia 

118 

76 



t 

I 

I 

V 

V 

B 

Ic 

119 

77 



I 

I 

I 

w 

w 

U 

Ie 


78 



I 

I 

I 

X 

X 

X 

ig 

121 

79 



~ 

' 


y 

y 

y 

grave 

122 

7A 






Z 

Z 

Z 

colon 

123 

7B 


# 

# 

# 

# 

{ 

{ 

{ 

numsign, lbrc 

HBI 

sg 


0 

0 

0 

0 

1 

1 

1 

atsign, vbar 

1 1 jj 

H 

i 

1 

1 

1 

1 

} 

) 

) 

ssq(3), rbrc 


7E 

= 

= 

= 

= 

= 

~ 

~ 

~ 

eq, eqv 

By 

7F 

11 

11 

" 

11 

ii 

DEL 

6 

0 

sdq, house 


BookMaster Symbols for Character Set 0697 (See Note (4)) 


Symbol 

Name 

Sym- 

bol 

Description 


Sym- 

bol 

Description 

aa 

k 

a acute 

Dstroke 

D 

D stroke 

Aa 

A 

A acute 

ea 

6 

e acute 

ac 

a 

a circumflex 

Ea 

E 

E acute 

acute 


accent acute 

ec 

e 

e circumflex 

Ac 

A 

A circumflex 

Ec 

E 

E circumflex 

ae 

A 

a umlaut 

ee 

e 

e umlaut 

aelig 

ee 

ae ligature 

Ee 

E 

E umlaut 

Ae 

A 

A umlaut 

eg 

e 

e grave 

AElig 

/E 

AE ligature 

Eg 

E 

E grave 

ag 

k 

a grave 

eq 

= 

equals 

Ag 

A 

A grave 

eth 

a 

eth, Icelandic small 

amp 

& 

ampersand 

Eth 

0 

Eth, Icelandic capital 

ao 

k 

a overcircle 

frac12 

’/2 

one half 

Ao 

A 

A overcircle 

frac14 

V* 

one quarter 

asterisk 

* 

asterisk 

frac34 

% 

three quarters 

at 

k 

a tilde 

grave 

■ 

accent grave 

atsign 

@ 

at sign 

gt 

> 

greater than 

At 

A 

A tilde 

hat 

A 

hat 

bslash 

\ 

back slash 

hyphen 

- 

hyphen 

cc 

5 

c cedilla 

ia 

f 

i acute 

Cc 

Q 

C cedilla 

la 

[ 

1 acute 

cdqf 

» 

French close dbl. quote 

ic 

T 

i circumflex 

cedilla 


cedilla 

Ic 

\ 

1 circumflex 

cent 

0 

cent 

ie 

I 

i umlaut 

colon 


colon 

Ie 

i 

1 umlaut 

comma 

, 

comma 

ig 

i 

i grave 

copyr 

© 

copyright 

ig 

i 

1 grave 

currency 

D 

currency international 

inve 

i 

inverted ! 

degree 

° 

degree 

invq 

6 

inverted ? 

div 

+ 

divide 

lbrc 

{ 

left brace 

divslash 

/ 

division slash 

lbrk 

[ 

left bracket 

dollar 

$ 

dollar 

lnot 

- 

logical not 


Symbol 

Sym- 


Symbol 

Sym- 


Name 

bol 

Description 

Name 

bol 

Description 

Ipar 

( 

left parenthesis 

rpar 

) 

right parenthesis 

Lsterling 

£ 

pound sterling 

sdq 

" 

straight double quote 

It 

< 

less than 

section 

§ 

section 

minus 

- 

minus operation 

semi 

; 

semicolon 

mu 

F 

mu 

slash 

/ 

slash right 

mult 

X 

multiply 

smultdot 


mult, dot small 

nt 

h 

n tilde 

splitvbar 

i 

i 

split vertical bar 

Nt 

N 

N tilde 

ss 

13 

German es-zet 

numsign 

# 

number sign 

ssq 

1 

straight single quote 

oa 

6 

o acute 

supl 

i 

superscript 1 

Oa 

6 

O acute 

sup2 

2 

superscript 2 

oc 

6 

o circumflex 

sup3 

3 

superscript 3 

Oc 

6 

O circumflex 

thorn 


thorn, Icelandic small 

odqf 

« 

French open dbl. quote 

Thom 

f> 

Thorn, Icelandic capital 

oe 

6 

o umlaut 

tilde 

“ 

tilde 

Oe 

6 

0 umlaut 

ua 

u 

u acute 

og 

6 

o grave 

Ua 

U 

U acute 

Og 

6 

O grave 

uc 

0 

u circumflex 

os 

0 

o slash 

Uc 

0 

U circumflex 

Os 

0 

0 slash 

ue 

u 

u umlaut 

ot 

0 

o tilde 

Ue 

u 

U umlaut 

Ot 

0 

0 tilde 

ug 

Ci 

u grave 

overline 


overline 

ug 

u 

U grave 

par 

u 

paragraph 

umlaut 

■■ 

umlaut 

percent 

% 

percent 

us 

_ 

underscore 

period 


period 

vbar 

1 

vertical bar 

plus 

+ 

plus 

xclam 

! 

exclamation point 

pm 

± 

plus-minus 

ya 

y 

y acute 

quest 

? 

question mark 

Ya 

V 

Y acute 

rbrc 

} 

right brace 

ye 

y 

y umlaut 

rbrk 

] 

right bracket 

yen 

¥ 

yen 


regtm ® registered trademark 


1-2 


ESA/390 Principles of Operation 



































Dec 

Hex 

81C 

EBCDIC(4) 
94C 037 500 

1047 

ISO I BM- 
-8 437 

-PC 

850 

BookMaster 

Symbol Names (2) 

128 

80 



0 

0 

0 

Q 

Q 

Os, Cc 

129 

81 

a 

a 

a 

a 

a 

ii 

ii 

ue 




B 

b 

b 

b 

BPH e 

e 

ea 




H 

c 

c 

c 

NBH a 

a 

ac 


El 

d 

d 

d 

d 

d 

IND a 

a 

ae 

133 

85 

e 

e 

e 

e 

e 

NEL a 

a 

ag 

134 

86 

f 

f 

f 

f 

f 

SSA A 

h 

ao 

135 

87 

g 

g 

g 

g 

g 

ESA 5 

S 

cc 

136 

88 

h 

h 

h 

h 

n 



ec 

137 

89 

n 

|9 

y 


u 



ee 

138 

8 A 



□ 





odqf, eg 

139 

8 B 



n 




e 

cdqf, ee 

140 

8 C 



n 



PLU T 

T 

eth, ic 

141 

8 D 



I] 



RI T 

i 

ya, ig 

142 

m 

■ 


□ 



SS2 A 

A 

thorn, Ae 

143 

n 

1 


II 

u 


SS3 A 

A 

pm, Ao 

144 

90 



o 

» 

° 

DCS E 

£ 

degree, Ea 

145 

91 

j 

j 

j 

j 

j 

PU1 a 

ae 

ael ig 

146 

92 

k 

k 

k 

k 

k 

PU2 H 

/E 

AElig 

147 

93 

1 

1 

1 

1 

1 

STS 6 

6 

oc 

148 

94 

m 

m 

m 

m 

m 

CCH 6 

6 

oe 

149 

95 

n 

n 

n 

n 

n 

MW 6 

6 

og 

150 

96 

0 

0 

0 

0 

0 

SPA u 

u 

uc 

151 

97 

P 

P 

P 

P 

P 

EPA u 

u 

ug 

152 

m 

a 



n 

q 

eh 

y 

ye 

153 

m 

WM 

u 


m 

r 

■»J 

0 

Oe 

154 

9A 

■ 



n 

a 


0 

aus, Ue 

155 

9B 




n 

0 

Hi 

0 

ous, cent, os 

156 

9C 



ae 

ae 

ae 

ST £ 

£ 


157 

in 






OSC ¥ 

0 


158 

9E 



k 

k 

k. 

PM Pt 

X 












159 

9F 



n 

n 

u 

ACP / 

/ 






EBCDI C (4) 


ISO 

IBM 

-PC 

BookMaster 

Dec 

Hex 

81C 

94C 

037 

500 

1047 

-8 

437 

850 

Symbol Names (2) 

160 

AO 



V 


u 

RSP 

a 

a 

mu( 6 ), aa 

161 

A1 



~ 

~ 

~ 

i 

i 

l 

tilde, inve, ia 

162 

A2 

s 

s 

s 

s 

s 

t 

6 

6 

cent, oa 

163 

A3 

t 

t 

t 

t 

t 

£ 

u 

u 

Lsterling, ua 

164 

A4 

u 

u 

u 

u 

u 

n 

n 

n 

currency, nt 

165 

A5 

V 

V 

V 

V 

V 

¥ 

N 

N 

yen, Nt 

166 

A 6 

w 

w 

w 

w 

w 

i 

i 

a 

a 

splitvbar, aus 

167 

A7 

X 

X 

X 

X 

X 

§ 

0 

Q 

section, ous 

168 

A 8 



n 

El 

a 

n 

n 

m 

umlaut, invq 

169 

A9 



1 

a 

i 



® 

copyr, lnotrev, 
regtm 

170 

AA 



19 

Eg 

n 



-< 

inve, aus, lnot 

171 

AB 



■■ 


H 



h 

invq, odqf, fracl 2 

172 

AC 






- 

I, 

% 

k 

Dstroke or Eth, 
lnot, fracl4 

173 

JJm 



? 


[ 

SHY 

i 

i 

Ya, lbrk, inve 

174 

AE 



p 

p 

p 

® 

« 

« 

Thorn, regtm, odqf 

175 

AF 




® 



* 

» 

regtm, overline, 
cdqf 

176 

B0 



/\ 

t 

- 

O 

iii 

in 

hat, cent, lnot, 
degree, boxl4 

177 

B1 



£ 

£ 

£ 

± 

El 


Lsterling, pm, boxl2 

178 

B 2 



¥ 

¥ 

¥ 

2 

if 

II 

yen, sup2, box34 

179 

B3 






3 



smultdot, sup3, bxv 

180 

B4 





CD 

- 

i 

| 

copyr, acute, bxrj 

181 

B5 



§ 

§ 

§ 

u 

i 

A 

section, mu( 6 ), 
bxl012, Aa 

182 

B 6 



l 

H 


11 

11 

A 

par, bx2021, Ac 


B7 



% 

% 

% 


A 

A 

fracl4, smultdot, 
bx0021, Ag 








i 



fracl 2 , cedilla, 
bx 0012 , copyr 

Era 









J 

frac34, supl, bx2022 

i 




u 

l 


a 

II 


lbrk, lnot, Ya, ous, 
bx 2020 

187 

BB 



] 

1 


» 

Tl 

ii 

rbrk, vbar, umlaut, 
cdqf, bxQ 022 

188 

BC 






% 

JJ 

il 

11 

overline, fracl4, 
bx 2002 

189 

BD 





] 

h 

t 

umlaut, rbrk, 
fracl 2 , bx 2001 , 
cent 


J 

190 

BE 






h 

¥ 

acute, frac34, 
bxl 002 , yen 


191 

BF 



X 

X 

X 

l 

1 

1 

mult, invq, bxur 


Additional ISO-8 Control-Character Representations 


APC 

Application Program 

HTS 

Character Tabulation Set 

PLU 

Partial Line Up 

SS3 

Single Shift Three 


Command 

IFS 

Information Separator Four 

PM 

Privacy Message 

ST 

String Terminator 

BPH 

Break Permitted Here 

IGS 

Information Separator Three 

PU1 

Private Use One 

STS 

Set Transmit State 

CCH 

Cancel Character 

IND 

Index 

PU2 

Private Use Two 

US 

Information Separator One 

CSI 

Control Sequence Introducer 

IRS 

Information Separator Two 

RI 

Reverse Line Feed (or Index) 

VTS 

Line Tabulation Set 

DCS 

Device Control String 

MW 

Message Waiting 

SCI 

Single Character Introducer 



EPA 

End of Guarded Area 

NBH 

No Break Here 

SOS 

Start of String 



ESA 

End of Selected Area 

NEL 

Next Line 

SPA 

Start of Guarded Area 



HTJ 

Character Tabulation with 

OSC 

Operating System Command 

SSA 

Start of Selected Area 




Justification 

PLD 

Partial Line Down 

SS2 

Single Shift Two 




Appendix I. EBCDIC and Other Codes 1-3 































81C 

EBCD I C (4) 
94C 037 500 

1047 

ISO 

-8 

IBM 

437 

-PC 

850 

BookMaster 

Symbol Names (2) 

192 

C0 



( 

{ 

{ 

A 

L 

L 

Ibrc, Ag, bxll 

193 

Cl 

A 

A 

A 

A 

A 

A 

i 

i 

Aa, bxbj 

194 

C2 

B 

B 

B 

B 

B 

A 

T 

T 

Ac, bxtj 

195 

C3 

C 

C 

C 

C 

C 

A 

[ 


At, bxlj 

196 

C4 

D 

D 

D 

11 

El 

A 

— 

_ 

Ae, bxh 

197 

C5 

E 

E 

E 

E 

E 

A 

f 

1 

Ao, bxcj 

198 

C6 

F 

F 

F 

F 

F 

/E 


a 

AElig, bxl210, at 

199 

C7 

G 

G 

G 

G 

G 

c 


A 

Cc, bx2120. At 

200 

C8 






E 

it 

A 

Eg, bx2200, Ag 

201 

C9 






E 

if 

If 

Ea, bx0220 

202 

CA 





nil 

£ 

JL 

JL 

Ec, bx2202 

203 

CB 



□ 


n 

E 

IT 

if 

oc, Ee, bx0222 

|M 

CC 



6 

6 

6 


If 

If 

oe, Ig, bx2220 


CD 



6 

6 

6 




og, la, bx0202 


CE 



6 

6 

6 

■ 1 

JL 

if 

JL 

ir 

oa, Ic, bx2222 





0 

6 

0 


X 

n 

ot, Ie, bxl202. 











currency 

208 

DO 



i 

} 


0 

JI 

a 

rbre, Dstroke or 











Eth, bx2101, eth 

209 

D1 

J 

J 

j 

j 

j 

N 

T 

b 

Nt, bx0212. 











Dstroke or Eth 

210 

D2 

K 

K 

K 

K 

K 

8 

IT 

E 

Og, bx0121 , Ec 

211 

D3 

L 

L 

L 

L 

L 

0 

II 

E 

0a, bx2100, Ee 

212 

D4 

n 

n 

□ 

n 

n 

0 

t 

E 

0c, bxl200. Eg 

213 

D5 

H 

ri 


H 

wm 

0 

r 

1 

Ot, bx0210. 











idotless 

214 

D6 

0 

0 

0 

0 

0 

111 

[T 

1 

Oe, bx012O, la 

215 

D7 

p 

p 

p 

p 

p 

X 

1 

I 

mult, bx2121, Ic 

216 


Q 

Q 

Q 

Q 

Q 

0 

f 

I 

Os, bxl212, Ie 

217 


R 

R 

R 

R 

R 

0 

J 

J 

Ug, bxlr 

218 




1 

1 

1 

0 

r 

r 

supl, Ua, bxul 

219 




u 

u 

u 

0 

i 

i 

uc, Uc, BOX 

220 

DC 



u 

ii 

ii 

ii 


■ 

ue, Ue, BOXBOT 

221 

DD 



u 

u 

Q 

? 

r 

T 

i 

ug, Ya, BOXLEFT, 











spl itvbar 

222 

DE 



u 

u 

u 

t> 

i 

i 

ua, thorn. 











BOXRIGHT, Ig 

223 

DF 



y 

y 

y 

B 

■ 

■ 

ye, ss, BOXTOP 


Dec 

Hex 

81C 

EBCDIC (4) 
94C 037 500 

1047 

ISO 

-8 

IBM 

437 

-PC 

850 

BookMaster 

Symbol Names (2) 

224 

EO 



\ 

\ 

\ 

a 

(X 

0 

bslash, ag, alpha, 











Oa 

225 

El 


NSP 

+ 

•r 

* 

a 

(3 

(3 

div, aa, ss 

226 

E2 

S 

S 

S 

s 

S 

a 

r 

3 

ac. Gamma, Oc 

227 

E3 

T 

T 

T 

T 

T 

a 

n 

0 

at, pi, Og 

228 

E4 

U 

U 

U 

U 

U 

a 

I 

6 

ae. Sigma, ot 

229 

E5 

V 

V 

V 

V 

V 

a 

o 

0 

ao, sigma, Ot 

230 

E6 

w 

W 

w 

W 

w 

ae 

U 

P 

aelig, mu(6) 

231 

E7 

X 

X 

X 

X 

X 

Q 

T 

t> 

cc, tau, thorn 

232 

E8 

Y 

Y 

Y 

Y 

Y 

e 

4> 

t> 

eg. Phi, Thorn 

233 

E9 

Z 

Z 

Z 

Z 

Z 

e 

© 

0 1 

ea, Theta(5), Ua 

234 

EA 



2 

2 

2 

e 

0 

0 

sup2, ec. Omega, Uc 

235 

EB 




3 

3 

e 

6 

0 

Oc, ee, delta, Ug 

236 

EC 



ii 

0 

0 

l 

00 

y 

Oe, ig, infinity, ya 

237 

os 



0 

0 

0 

l 

<t> 

i 

Og, ia, phi, Ya 

238 

EE 



0 

0 

0 

l 

€ 


Oa, ic, epsilon. 











overline 

239 

EF 



0 

0 

0 

l 

n 

' 

Ot, ie, intersect, 











acute 

240 


0 

0 

0 

0 

0 

5 

= 

SHY 

eth, identical 

241 

FI 

1 

1 

l 

1 

l 

n 

± 

± 

nt, pm 

242 

F2 







> 

= 

og, ge, eq 

243 

F3 






H 

< 

% 

oa, le, frac34 

244 

m 

4 

4 

4 

4 

4 

6 

r 

1 

oc, inttop, par 

245 

tn 

5 

5 

5 

5 

5 

6 

j 

§ 

ot, intbot, section 

246 

El 

6 

6 

6 

6 

6 

6 


+ 

oe, div 

247 

F7 

7 

7 

7 

7 

7 

+ 


- 1 

iiv, nearly(5). 











cedilla 

248 

F8 

8 

8 

8 

8 

8 

0 

o 

o 

os, degree 

249 

F9 

9 

9 

9 

9 

9 

Si 



ug, lmultdot, umlaut 

250 

FA 



3 

3 

3 

H 



sup3, ua, smultdot 

251 

FB 



0 

0 

Ifl 

H 

V 

m 

Uc, uc, sqrt, supl 

252 

FC 



0 

u 

u 

u 

n 

3 

Ue, ue, supn, sup3 

253 

FD 



0 

0 

0 

y 

2 

2 

Ug, ya, sup2 

254 

FE 



0 

0 

0 

i> 

■ 

■ 

Ua, thorn, sqbul 

255 

FF 

EO 

EO 

EO 

EO 

EO 

y 

RSP 

RSP 

ye 


Notes: 

(1) The ASCII controls and graphics are from ANSI X3.4. The ISO-8 controls are from ISO 6429, and the graphics 
are from ISO 8859-1. The ISO-8 graphics are code page 00819, named ISO/ANSI Multilingual. IBM-PC controls 
and graphics are shown. The graphics are common to code page 00437, named Personal Computer, and code 
page 00850, named Personal Computer - Multilingual Page. Code pages 00437 and 00850 are shown separately 
beginning at X'80 1 , after which they diverge in content. 

( 2 ) The symbol names shown are to be preceded by an ampersand (&) and followed by a period (.) to form a symbol. 
Source: IBM BookMaster User's Guide Release 4.0, SC34-5009. 

( 3 ) ASCII, ISO-8, and IBM-PC X'27' and EBCDIC X'7D' are an apostophe having the appearance of a straight 
single quote. The BookMaster “apos” produces a character having the appearance of an accent acute. 

( 4 ) Five columns of EBCDIC graphics are shown. The first is the 81 -character character set 0640, called the syntactic 
character set, that is mapped the same on all EBCDIC code pages. The second is the standard IBM 94-character 
character set mapped on code page 00037. The third is code page 00037, named USA/Canada - CECP (Country 
Extended Code Page). The fourth is code page 00500, named International #5. The fifth is code page 01047, 
named Latin 1/Open Systems. Code pages 00037, 00500, 01047, and 00819 (ISO-8) all map the 189-character 
character set 0697. Source: National Language Support Reference Manual Volume 2, SE09-8002. 

(5) f, =*, and 0 are of nonstandard width. 

(6) EBCDIC X'AO 1 and ISO-8 X'B5' are micro but resemble mu. The BookMaster “usee” produces a character of 
nonstandard width. 
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